Skip to content

Properly handle moving issues

Update

Option B - Clone, Close(Delete), & Redirect.

I think we can still make this look as a proper move to the end user, but it would:

  • require more work on some of the issue's associated data. e.g. on some associated data we might have had to only update namespace_id now we'll need to create a new record and remove the old association record.
  • potentially make the move functionality(especially bulk move) slower, thought I am pretty sure that even with Option A a comprehensive implementation of the move functionality would have not been a fast feature.

Having that ☝ I think we can perhaps close this issue and move the discussion to how we want to approach the move functionality to the https://gitlab.com/gitlab-org/gitlab/-/issues/477278 and discuss in more detail how we would need to handle each associated data in particular when moving an issue. We'd definitely want the UX input on this.

Implementation will be tracked in separate issues.

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

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...

  • 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, the confirm 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.
  • 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

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

Links / references

Edited by Gabe Weaver