Moving issues across repositories

[lefta]

copy issue; close orig; move comments on orig(they are moved); setup a redirect to new location

---

Gitea is great for small projects, but some features are missing for (very?) big projects, Atom being the perfect example of what I am meaning. With this kind of huge project, some issues arise. I'm dividing those issues in multiple bug reports for easy tracking.

One of those issues is that it is sometimes hard to guess the exact origin of a bug. One may report a bug in the wrong component, or not know where the bug exactly comes from. In the prototyping stage, it may even happen that features move from one repository to another, requiring to move associated bugs with them (I got the case). This currently require closing and copy-pasting bugs, which is counter productive and makes bug tracking harder.

Being able to move bugs across repositories would greatly ease the development of such big project.

---

Note: on move create a redirect ... so kinda add issue type redirect and let rest stay as is. create new issue in new repo and Copy issue. second change direct referenced content (comments...)

[bkcsoft]

Would cloning the issue over to the new repo and then closing the new one suffice? (given that it's just a button-click away)

[lefta]

I'm not sure to see what you mean, but I see multiple ways to implement it:

• Cloning the issue to the new repo, add a link in the original one and close it: this would be the easier but would have the poorest percepted quality in the end user point of view. (Is that what you mean?)
• Change the associated repository and the issue number (as it can't stay the same), and update all references to it: this would be the harder but would have the best percepted quality.
• Change the associated repository id and the issue number, like before, but create a new issue to replace the old one which would transparently redirect to the new one at run time: this would be a balance between the work needed and the percepted quality of the result.

Note that I did not dig in the implementation details of Gitea, my solutions are mostly based on assumptions so I may not see all implications of their implementation. My personal favorite is the third, but the first one would be sufficient for me.

EDIT: I just though, sometimes we also need to "cherry pick" issues from another repository without deleting the original. For example, when forking a project, we sometimes need to get issues from the parent. This is well demonstrated with gogs and gitea, where gitea ends up with issues containing only a link to the gogs one. It would be nice if we could also "copy" an issue from another repository (related or not). I still have to think a little more on how to make all of this work together though, I will report back my ideas once it gets clearer in my mind.

[lefta]

Finally, here is how I would see it:

• In the UI part, I would replace the close button with a dropdown called something like actions (I don't really like this wording but I could not find better). This dropdown would contain close issue, move issue to... and copy issue to.... The two new entries would redirect to a page asking to which repository the issue have to be copied/moved (called "the target repository" later in my description), with a listing of all repositories on which the current user have write access (or at least all its repositories and its organization repositories, if any). Of course, move issue to... would only be displayed if the user have write access to the current repo.

• About copying in the backend part, it would create a new issue in the target repository and copy everything associated to the issue (comments, labels...). After this, both issues would be independent, something like an "issue fork".

• About moving in the backend part, it could copy the issue to the target repository and close the original one in a first time (maybe with a comment like Moved to <repository>). This would reuse the copying code and would be sufficient for most users (including me).

• To make moving cleaner in a second time, I would change the issue repository to the target repository id and the issue number to the next available one (if this is acceptable and possible for you). I would then create a new issue in the source repository with the same number, giving it a moved status. This new issue status would be displayed in the closed issues category and would redirect to the target repository issue when open.

• Later, we could create a new issue type: mirrored. This issue type would redirect to the original issue and should be overcomplicated based on the work done before. But that is another story...

Of course, this is only a draft to expose my ideas and is widely open to discussion

[tboerger]

Sounds like a useful feature, but I would put only the additional actions into a drop down, close should stay as it is

[lefta]

I do not have any problem with it, let's let the close button as it is. Otherwise, does it look good to you? Is the third point technically possible? I guessed some implementation details when thinking about it...

[bkcsoft]

Could use this as a reference :) https://about.gitlab.com/2016/04/20/feature-highlight-move-issues/

[maxgaurav]

Any update on this feature?

[lunny]

Nobody are working on this.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[jrhoffa]

This would be a great feature. I just created a pile of issues under the wrong project and don't relish copy-pasting them one by one.