Moving issues across repositories #146

@bkcsoft commented on GitHub (Dec 25, 2016):

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)

@bkcsoft commented on GitHub (Dec 25, 2016): 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)

GiteaMirror commented

@lefta commented on GitHub (Dec 25, 2016):

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 commented on GitHub (Dec 25, 2016): 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.

GiteaMirror commented

@lefta commented on GitHub (Dec 27, 2016):

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

@lefta commented on GitHub (Dec 27, 2016): 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

GiteaMirror commented

@tboerger commented on GitHub (Dec 27, 2016):

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

@tboerger commented on GitHub (Dec 27, 2016): Sounds like a useful feature, but I would put only the additional actions into a drop down, close should stay as it is

GiteaMirror commented

@lefta commented on GitHub (Dec 27, 2016):

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

@lefta commented on GitHub (Dec 27, 2016): 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...

GiteaMirror commented

@bkcsoft commented on GitHub (Dec 27, 2016):

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

@bkcsoft commented on GitHub (Dec 27, 2016): Could use this as a reference :) https://about.gitlab.com/2016/04/20/feature-highlight-move-issues/

GiteaMirror commented

@maxgaurav commented on GitHub (Jan 18, 2019):

Any update on this feature?

@maxgaurav commented on GitHub (Jan 18, 2019): Any update on this feature?

GiteaMirror commented

@lunny commented on GitHub (Jan 19, 2019):

Nobody are working on this.

@lunny commented on GitHub (Jan 19, 2019): Nobody are working on this.

GiteaMirror commented

@stale[bot] commented on GitHub (Mar 20, 2019):

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.

@stale[bot] commented on GitHub (Mar 20, 2019): 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.

GiteaMirror commented

@jrhoffa commented on GitHub (Aug 1, 2020):

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.

@jrhoffa commented on GitHub (Aug 1, 2020): 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.

GiteaMirror commented

@rnwgnr commented on GitHub (May 27, 2021):

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

@rnwgnr commented on GitHub (May 27, 2021): This seems to be closely related (a duplicate?) of #2991

GiteaMirror commented

@n3storm commented on GitHub (Jun 15, 2021):

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.

@n3storm commented on GitHub (Jun 15, 2021): 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.

GiteaMirror commented

@6543 commented on GitHub (Jun 15, 2021):

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

@6543 commented on GitHub (Jun 15, 2021): 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

GiteaMirror commented

@besworks commented on GitHub (Sep 27, 2021):

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);

@besworks commented on GitHub (Sep 27, 2021): 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); ```

GiteaMirror commented

@jhaand commented on GitHub (Nov 11, 2021):

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.

@jhaand commented on GitHub (Nov 11, 2021): 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.

GiteaMirror commented

@faengl commented on GitHub (Dec 21, 2021):

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.

@faengl commented on GitHub (Dec 21, 2021): 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.

GiteaMirror commented

@derpmacos commented on GitHub (Aug 22, 2022):

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.

@derpmacos commented on GitHub (Aug 22, 2022): 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.

GiteaMirror commented

@lunny commented on GitHub (Aug 23, 2022):

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

@lunny commented on GitHub (Aug 23, 2022): When moving an issue, the index will be changed and old index will be dropped.

GiteaMirror commented

@derpmacos commented on GitHub (Aug 23, 2022):

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

@derpmacos commented on GitHub (Aug 23, 2022): Current approach is manually create, copy-paste, and then close old issue - so any improvement on that workflow would be useful to us.

GiteaMirror commented

@OhSoGood commented on GitHub (Jan 26, 2023):

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.

@OhSoGood commented on GitHub (Jan 26, 2023): 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.

GiteaMirror commented

@hoffmannlin commented on GitHub (Feb 10, 2023):

this function is very useful

why always been cancel ?

@hoffmannlin commented on GitHub (Feb 10, 2023): this function is very useful why always been cancel ?

GiteaMirror commented

@Area128 commented on GitHub (Feb 25, 2023):

For lack of a vote button, this is another comment supporting this idea. It would indeed be very useful to be able to move issues across repositories.

@Area128 commented on GitHub (Feb 25, 2023): For lack of a vote button, this is another comment supporting this idea. It would indeed be very useful to be able to move issues across repositories.

GiteaMirror commented

@KlavsKlavsen commented on GitHub (Aug 18, 2023):

Wow.. amazing this isn't there yet.. it would REALLY be helpful when trying to split things up.. so another vote up :)

@KlavsKlavsen commented on GitHub (Aug 18, 2023): Wow.. amazing this isn't there yet.. it would REALLY be helpful when trying to split things up.. so another vote up :)

GiteaMirror commented

@timmwille commented on GitHub (Sep 18, 2023):

Is this still pending?

@timmwille commented on GitHub (Sep 18, 2023): Is this still pending?

GiteaMirror commented

@alanmels commented on GitHub (Nov 20, 2023):

Would be really nice to have this feature around.

@alanmels commented on GitHub (Nov 20, 2023): Would be really nice to have this feature around.

GiteaMirror commented

@lunny commented on GitHub (Nov 20, 2023):

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

@lunny commented on GitHub (Nov 20, 2023): 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

GiteaMirror commented

@JGKle commented on GitHub (Feb 19, 2024):

Really need this. Manual copy-pasting is pretty agonizing (and also loses the original creation date, which can be useful context to have).

@JGKle commented on GitHub (Feb 19, 2024): Really need this. Manual copy-pasting is pretty agonizing (and also loses the original creation date, which can be useful context to have).

GiteaMirror commented

@PierreLouisPAUGAM commented on GitHub (Feb 27, 2024):

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.

@PierreLouisPAUGAM commented on GitHub (Feb 27, 2024): 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.

GiteaMirror commented