Issue label not being applied when moving from open to label list
When dragging an issue from the 'open' list to 'in progress', the operation appears to succeed but a reload shows that the label was never applied. The issue remains in the 'open' list.
To reproduce:
- In the UI, create a new group, create a new project under it called
project1
andproject2
. - In console, create a new label under
project2
that has aproject_id
and agroup_id
.
> project = Project.last
=> #<Project id:27 group/project2>>
> label = project.labels.create(project_id: project.id, group_id: project.group.id, title: "corrupted", color: "#ff0000")
- In the UI, create a board for
project1
by visitinghttps://gdk.localhost:3443/group/project1/-/boards
- Back in the same console, add a new list in
project1
with the corrupted label:
> board = Board.last
> list = List.create(board_id: board.id, label_id: label.id, position: 1)
- Reload
- The issue is back in
open
with no error.
Thank you to @shoyle who raised it originally.
Problems
There are several problems here:
- data inconsistency (some project labels have a
group_id
) - lack of constraints on project vs group labels - we're not sure how this project label got a
group_id
in the first place -
users can create a label list in a project board with a project label that is NOT of that project(solved) - the PUT request returns a 200, but it failed
- the UX shows that the issue's state changed when it did not
Implementation Plan
The easiest first iteration is to let the user know that a problem has occurred rather than let them do a bunch of work that isn't actually being saved. Then we can increment the solution from there.
- return an
UnprocessableEntity
instead of 200 when this occurs (which will alert the user that it didn't work) -
✅ prevent adding of new label lists in project boards where the project label'sproject_id
doesn't match the project (filter them out) - remove any label lists for project boards where the project label's
project_id
doesn't match the project (there will be no issues in that list anyway) - then we can fix the data consistency and then put down the constraint (ie. that a label must not have both a
project_id
and agroup_id
, and that their type must match whatever id they have). - we can then clean up the business logic put down in 3. since our current logic would be sufficient?
Issue blocked
This issue is blocked by the boards migration to Apollo.
Edited by charlie ablett