Ability to move issues between projects

I have two projects.

I want to move some issues from project #1 to project #2.

Is there any way to add this feature to the GitLabCE?

Looks like this feature has not been implemented yet.

However, the Gitlab team approved the idea and are now accepting merge requests for that feature (if it meets the guidelines set in the above link).

Sounds like a fun project to work on and one that many in the community would benefit from. I'll reply to this post in the future if I start a branch for this (or find someone who's already has).

Ok, thank you, Stephen.

Added feature proposal label

@JobV I propose to label accepting merge requests.

Additional, what about renaming feature request to feature proposal? Issues act more as a proposal, which are implemented by MRs.

@razer6 I'm down with that, removing request also gets rid of the assumption the requestor won't implement it.

@sytses @razer6 +1 I'll change and add.

@blackst0ne-ru @stev0thegreat awesome, would love to see this.

@stev0thegreat feel free to post updates / status here. Everyone is always happy to help with decisions and roadblocks.

Added ~123454 label

Added ~131895 and removed feature proposal labels

Milestone changed to 8.5

This is really needed (for example Emily asked for it yesterday) so I've assigned it a milestone.

Thanks @sytses

Guys, what about moving issues between GitLab projects on different GitLab instances (different servers)?

I mean, couldn't the GitLab's API be used for it? I think fetching all issues (and related comments) from one project with the API and create new issues (and commends) to the other endpoint may be great too, don't you think?

@mathias2 Moving individual issues between servers is hard. Per project is doable (we already import GitHub issues). So if we don't support importing GitLab issues per project import feel free to create a feature request for it.

Okay, this can be tricky but that would be a very nice feature. Too bad we can't, using current API, set a date when creating notes or issues...

FYI, I urgently need this feature (2 GitLab instances using different RDBMS) and I'm currently working on a CLI tool that will move issues between projects on differents GitLab servers (using API tokens).

Won't be perfect, but will do the job. It's being written in Go and expects a very simple YAML file for API tokens and basic projects information. Most probably I will provide a binary release on Github soon.

@mathias2 OK, thanks.

@voidscale Were you able to write a CLI tool to do this ?

@IndianaTux Yes. Almost working fine. Planning a public release by the end of the week.

I just published a gitlab-copy tool on GitHub:

https://github.com/gotsunami/gitlab-copy.

I successfully used it to copy projects with lots of issues from one GitLab instance to another.

You can go to the releases section to grab a standalone binary and start using it. Please consider this it beta software. PR are very welcome!

mentioned in issue #4197 (closed)

A month ago I had similar problems and hacked up something myself. (Too bad I didn't check back here a few days ago.)

It's a little different: written in Java and intended to transfer a project's milestones, issues, and notes between different servers (but where I didn't have connectivity between them). It should skip existing milestones and issues.

https://github.com/FraggedNoob/GitLabTransfer

Definitely beta, but if someone is looking for ideas...

gitlab-copy, above, looks pretty nice too.

Added ~122770 label

mentioned in issue gitlab-com/www-gitlab-com#454 (closed)

mentioned in issue #8938 (moved)

@voidscale Thanks!, works great, created a small FR: https://github.com/gotsunami/gitlab-copy/issues/6

Reassigned to @grzesiek

Assignee removed

Reassigned to @grzesiek

@DouweM, @dbalexandre I have few questions:

1. Do you think that when moving an issue to another project we should preserve issue ID (project1#123 -> project2#123)?

   This will probably cause that next issue in project2 will be 124, even if this is a first issue in that project, which may be confusing. Should we then fill missing ID with issues that will be added next (this also may be confusing)?

2. What should we do with issue that is being moved? Should it just disappear?

   It may be also confusing as there may be already some references/cross-references to it, and it may be performance killer to try changing those references. Closing issue in project1 and duplicating it in a project2 may be also a confusing (I would be better probably to display notification in project1#123 that is has been moved to project2#123 when someone views it).

3. Should we also create an API dedicated for moving issues from project to project?

4. How should we handle a situation when issue-related references (labels, list of members, milestones) doesn't match those available in a new project?

   Member assigned to issue in project1 may not be a member of project2. Similar problem with milestone, labels, participants. Should we just remove associations that doesn't match those available in a new project?

@DouweM I think it would be difficult to ship this feature in 8.5 as there a some interesting concerns that are not addressed yet. This feature may be difficult to implement as issue is connected to a project in many various ways, like references, internal ids, participants, author, updater, assignee, notes, system notes, permissions, labels, milestones, notes content, merge requests (closes, fixes) etc.

At this moment issues are tightly coupled with a project and we need to know our strategy before making assumptions about implementation timeline for this feature.

@grzesiek

1. no
2. close it, put a system note that it is moved and where
3. yes, but doesn't have to be shipped on the same release
4. yes, remove

As discusses with @JobV we will try to ship this in 8.5, if it will be impossible because of no capacity available, it can be handled to someone else, if because of complexity and code-level-difficulties this can be moved to 8.6. @JobV did I understand it correctly?

@grzesiek yep, no need to ask :)

@JobV I have another question about strategy. We probably want to move also all comments and system notes related to given issue. What should we do with all references inside those comments and system notes (references to another issues, merge requests, labels, member who are not members in a new project, milestones, participats)? Should we parse and update each entry (like "Hi, this is a duplicate of #123" -> "Hi, this is a duplicate of old-project#123" or simply do not move anything except an issue itself?

Added ~14281 label

@grzesiek With the Markdown rendering/reference pipeline, it should be possible to replace the references by the cross-reference version, but I think it's okay to do that in a later release.

@DouweM But until we replace relative references like #123 all those references will be broken in issue that has been moved, and this is not good, right?

@grzesiek I agree. I don't currently see a better way than to change the note text to have the full cross-reference, but Banzai doesn't currently give us the start..end range of the reference in the original text, which would make that a lot easier. A regex won't do, since we ignore references in a number of cases, like when it's inside a code block.

@rspeicher Do you have another idea of how to handle references on moved issues, or a way to get at that reference range?

Simply using the original project for context[:project] won't do, since that's used for access checks as well, as well as rendering (it would still show #123 instead of old/project#123), and editing notes would be confusing since the context would still be the original project.

mentioned in merge request !2831 (merged)

@rspeicher Do you have another idea of how to handle references on moved issues, or a way to get at that reference range?

I don't. Getting the range would require some major redesign of the filters, I think.

@grzesiek @DouweM we should keep it as simple as possible. Lossy if necessary. I prefer to not include a system note or reference than to have incorrect links.

Unfolding the urls is probably the best option if you can't make a reference, but otherwise a note without a link is fine / removing the reference.

@JobV I agree that this should be simple, but I also think that this should not be misguiding. If we have a note content 'This is a continuation of !2831 (merged)', after moving this issue to another project this !2831 will be invalid in context of a new project, and both, link and merge request number, become invalid, as there is no !2831 in a new project or it is there, but it is not the one that was originally referenced.

So we can not remove link - number will be still invalid/misguiding (and this is handled on the another level of implementation), and unfolding link is basically the same thing as expanding local reference to cross project reference/changing note text, as is difficult in terms of implementation (but not impossible of course).

So I think the only valid solution here is to refactor and modify Banzai to make it possible to iterate references. It is also possible that I'm missing an obvious and simple solution, so I appreciate all suggestions

and unfolding link is basically the same thing as expanding local reference to cross project reference/changing note text, as is difficult in terms of implementation (but not impossible of course).

This seems to be the only good option.

All right, I've changed the milestone to 8.6. Let's get it as close to ready as possible, and then we'll worry about rewriting references next month :)

Milestone changed to 8.6

mentioned in issue gitlab-com/marketing#11 (closed)

mentioned in issue gitlab-com/blog-posts#166 (closed)

Status changed to closed by merge request !2831 (merged)

Status changed to closed by commit 3fca30d2

mentioned in commit 3fca30d2

mentioned in commit ab3681d1