Summary
Issue create and update accepts related IDs without checking that they belong to the same workspace and project.
Where I saw it
- api/internal/handler/issue.go accepts state_id, parent_id, assignee_ids, and label_ids from the request body.
- api/internal/service/issue.go writes those IDs directly or replaces join rows without validating their ownership.
- api/internal/store/issue.go adds assignee and label join rows with only the issue workspace/project copied from the issue.
Why this is a problem
A bad or stale client can attach unrelated data to an issue. Examples:
- a state from another project
- a label from another project
- a parent issue from another workspace
- an assignee who is not a member of the workspace or project
This can leave the database in a confusing state and make filters, boards, analytics, notifications, and activity feeds behave incorrectly.
Suggested fix
- Validate state_id against the same project.
- Validate label_ids against the same project.
- Validate parent_id against the same workspace and decide whether cross-project parents are allowed.
- Validate assignee_ids against workspace membership, and project membership if project membership is meant to be strict.
- Return 400 for invalid IDs instead of silently accepting them.
- Add API tests for cross-project and cross-workspace IDs.
Acceptance criteria
Checked on
main at f8e5946
Summary
Issue create and update accepts related IDs without checking that they belong to the same workspace and project.
Where I saw it
Why this is a problem
A bad or stale client can attach unrelated data to an issue. Examples:
This can leave the database in a confusing state and make filters, boards, analytics, notifications, and activity feeds behave incorrectly.
Suggested fix
Acceptance criteria
Checked on
main at f8e5946