Properly handle moving work items
Problem to solve
We are currently doing a ton of extra work to provide a coherent user experience when we move or promote an issue. This stems from the fact that we don't actually move the issue, we create a copy and close the old issue. These results in a plethora of usability problems and fringe cases that cause a lot of confusion, duplicate efforts, etc.
Intended users
- Parker (Product Manager)
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Presley (Product Designer)
- Devon (DevOps Engineer)
- Sidney (Systems Administrator)
- Sam (Security Analyst)
- Dana (Data Analyst)
Further details
- Makes it easier to collaborate on issues by preventing people from accidentally working on issues that have been closed and moved.
- Helps everyone before more efficient as they won't have to remember to do a bunch of additional actions after they move an issue (like removing the old issue from milestones, etc.).
- Helps provide a more accurate burndown chart for milestones.
Proposal
When moving an issue...
- Move the issue to the target project without creating a copy.
- Add a
301 Moved Permanently
Redirect - Properly store canonical location of the issue in the redirect locations so there is only ever "one hop" from any previous issue location.
- Update the "moved" system note to reference the user who initiated the move.
Handling sad paths...
- To prevent someone from hijacking an issue, show warning and prevent the moving of issues outside of the highest parent group.
- To deter data loss on an issue, show a unified warning when the target project/group:
- does not have 1 or more labels that the current issue has.
- does not have access to the same epic and/or milestone.
- Is moving from a public to private project.
- The user should check a box next to each item then
confirm
the move with the understanding that those items will disappear. If the checkboxes haven't been checked, theconfirm
button is disabled. - The warning dialogue should provide helpful information next to each item such as -- using top level group labels and milestones.
Potential follow up to maintain transparency...
If an issue is moved to a project for which current participants do not have access, consider:
- Sending those participants an email notifying them who moved the issue, that they no longer have access, and include all the current issue's relevant content such as description and comment threads.
Alternate proposal that is less desirable:
Option B - Clone, Close, & Redirect
When moving an issue...
- To prevent someone from hijacking an issue, show warning and prevent the moving of issues outside of the highest parent group.
- On the old issue:
- To deter data loss on an issue, show a unified warning when the target project/group:
- does not have 1 or more labels that the current issue has.
- does not have access to the same epic and/or milestone.
- Is moving from a public to private project.
- The user should check a box next to each item then
confirm
the move with the understanding that those items will disappear. If the checkboxes haven't been checked, theconfirm
button is disabled. - The warning dialogue should provide helpful information next to each item such as -- using top level group labels and milestones.
- Disable commenting globally.
- Update the "moved" system note to reference the user who initiated the move.
- Automatically redirect to new issue ONLY IF the user has permissions to access the cloned issue.
- Exclude old issue from showing up on Milestones and Epics.
- To deter data loss on an issue, show a unified warning when the target project/group:
- On the new issue:
- Add a system note that includes a URL attribute to allow clicking back to the old issue without being redirected.
- Update the "moved" system note to reference the user who initiated the move.
- Fix all the things that are currently not working when moving an issue:
- Copy those participants that have access
- Copy votes and award emojis
- Copy description versions
- Copy Designs
- Fix missing system notes
- Properly store canonical location of the issue in the redirect locations so there is only ever "one hop" from any previous issue location.
Moving forward, we will also have to:
- Properly handle moving tasks to the new issue: #2036 (closed)
- Make decisions on how to handle each and every additional object/artifacts that is introduced as a part of an issue or associated to an issue and make sure we are handling the logic of whether or not to include both the new and old issue on the views.
Potential follow up to maintain transparency...
If an issue is moved to a project for which current participants do not have access, consider:
- Sending those participants an email notifying them who moved the issue, that they no longer have access.
Permissions and Security
- No differences between current permissions required to move issues.
Documentation
- Documentation will be required, especially https://docs.gitlab.com/ee/user/group/epics/
- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#moving-issues
Testing
- It should be straightforward to write an integration test for this.
- We should specifically test moving an issue more than once and that the canonical redirects are correct and only result in 1 hop.
What does success look like, and how can we measure that?
- Users stop commenting on old, closed issues that have been moved.
- Burndown charts have more accurate data.
- We can close 20+ open issues around undesirable complications with our current move process.
What is the type of buyer?
- Core