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.

[rnwgnr]

This seems to be closely related (a duplicate?) of #2991

[n3storm]

We have a triage project where we work on misc issues.
When issue grows to own project, it would be great to be able to move issues.

[6543]

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

This schould prevent links from breaking and you have a nice redirect. eafen links to issuecomment schould be aave if we move them rather than copy-them

[besworks]

I ran into a situation where I needed to merge two repos into a new unified one, including transferring all issues/projects. I ended up doing this with a few SQL queries. First I forked one of the original repos and got the id of this new repo. Then...

The first query changes the repo_id of all issues from both original repos to match the new id found above and generates a new index for them starting at 1.

SET @rownum:=0; UPDATE issue SET repo_id=5, `index`=(SELECT @rownum:=@rownum+1) WHERE (repo_id=2 OR repo_id=3);

The next two queries update the issue counts in the new repo. I'm sure you could inject another query in here to count the number of total/closed issues but I just read the numbers from the web interface and entered them manually.

UPDATE repository SET num_issues=[ENTER_TOTAL_COMBINED_NUMBER_OF_ISSUES] where id=5;
UPDATE repository SET num_closed_issues=[ENTER_COMBINED_NUMBER_OF_CLOSED_ISSUES] where id=5;

The last query changes the repo_id for any projects to match the new repo.

UPDATE project SET repo_id=5 WHERE (repo_id=2 OR repo_id=3);

Keep in mind that this process will remove these issues and projects from their original repo. This might not be a perfect solution but hopefully somebody finds it useful.

Edit: Turns out that I also needed to update the action table as well to fix the dashboard entries. I imagine this query might have bigger consequences... I wouldn't suggest doing this if you need to keep the history of the original repos intact. USE AT YOUR OWN RISK

UPDATE action SET repo_id=5 WHERE (repo_id=2 OR repo_id=3);

[jhaand]

Our organisation would really benefit if it was possible to copy or move issues to other repository.
Issues found on system level can then be copied to the appropriate repository to fix them. Also being able to cross link them would make it easier to forward the status upstream when they're fixed.

[faengl]

This feature would be very much appreciated!
In our case we started off working on an R-Shiny app and later decided to put all the processing logic into a separate R-package. The Package is now developed in a repository of it's own. Some of the older issues concerning the Package were not closed and still lived in the old shiny repository. We also continued to create new issues in the old repository. This is because we only wanted to have one point to access issues for the R-Package.
Now it would be really nice to be able to move all issues to the correct repository. Also closed issues should live in the correct repository for the sake of consistency.

[derpmacos]

Likewise would be appreciated as we find issues are generally logged in an adhoc manner by users at the organisation level, and then later identified by devs as belonging with a particular component in its own repo.

[lunny]

When moving an issue, the index will be changed and old index will be dropped.

[derpmacos]

Current approach is manually create, copy-paste, and then close old issue - so any improvement on that workflow would be useful to us.

[OhSoGood]

If one uses @besworks' SQL queries above (thank you @besworks !), please note there are a few others to run to keep your gitea stable. Pitifully, I have not written all here. From what I remember:

• Update table issue_index: that one contains the issues' max_id per repo
• Pay attention to pull-request tables. Ex: pull_request.

As gitea database may evolve between the date of this post and the date where you will try this manual migration, I recommend that you export from your current database all tables' definitions (i.e. without data) and that you look for the keyword repo_id to determine which tables may be impacted. That way, you'll minimize the risk to break something. In my case, everything seemed to run fine but, a day after migration, we realizes some functionalities were broken (ex: to add a new ticket) and managed to fix it.

[hoffmannlin]

this function is very useful

why always been cancel ?

[lunny]

This is a to-do list to implement it.

• Modify issue's repo id
• Modify issue's index id because the possible index conflicts
• Add a new table named issue_redirect, so that visiting old issue will be redirected to new issue URL
• Update all subscriptions according to new repository permissions or delete all of them
• Update old repository issues search index and new repository issues search index

[PierreLouisPAUGAM]

This feature would also help a lot when synchronising gitea issues with tickets from another source (like GLPI for example) as user's often make errors when assigning tickets to projects or applications.

[timmwille]

there is a constructive discussion on this ongoing here too:

https://codeberg.org/forgejo/forgejo/issues/1280

(in best case collaboration instead of double work) 🙏

[lunny]

I have given the todo list in #453 (comment) maybe we can improve it together.