[bug]: Unable to transfer or update a task to another project

[melgo-tb]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

While trying to change the project by clicking on the project and selecting another project it moves back to the same project. Unable to move tasks across projects

Steps to reproduce

1. Create a task in a project
2. Edit Task
3. Try changing task of the project
4. Frontend re-renders back to original project after selecting another project

Browser

Google Chrome

Version

Cloud

[vihar]

Currently, our platform doesn't support the transfer of issues from one project to another, @melgo-tb. The only way to have a relationship between issues in different project is via Blocks and Blocked by attributes. Good news, though, transferring issues is already in dev.

Curious. When do you move issues from one project to another today? Care to talk about your use cases? If a call's better, here's my calendar.

[melgo-tb]

Hi @vihar, The issue we're encountering is that tasks are being inadvertently added to the wrong project. This typically happens when tasks are created from the "All Issues" page. By default, tasks get assigned to a certain project, which often goes unnoticed by the user. We only realised this mistake after adding all the tasks. Currently, the only solution seems to be deleting and recreating these tasks, which is quite tedious.

Is there a functionality to duplicate tasks? This feature could simplify the process of correcting such errors. We initially needed to transfer issues between projects because they were mistakenly added to the incorrect project.

[vihar]

Thanks, @melgo-tb, for the insights. Here's a summary to address these points:

• We've noted that when creating issues from the 'All Issues' page, the user experience could be enhanced. Specifically, it should be clearer which project the issues are being added to.
• It's important to enable switching issues between projects. This way, if an issue is mistakenly added to the wrong project, users can easily reassign it to the correct one.

Regarding the idea of issue duplication, this feature is already available on the platform. Here's how you can use it:

• In any project layout, right-click on an issue and choose Make a copy.
• A modal will appear with all the issue details. Simply update the project key in the top-left corner.
• This action will create a duplicate of the issue in the selected project.

While this method currently serves as a hack, we'll work on making this experience better.

[athornfam2]

Adding that I was looking for this feature as well. Whether its projects or different teams I've used this often in Jira.

[landon-buttars-fleetfix]

@vihar I have a use case where one project encompassed all of the tasks and when we identified the need to break it out into another project we needed to move many of the tickets out of the old project and into the new.

[spsneo]

For me also this is an important feature. A lot of times - project assignment is not 100% clear till the time it is discussed with the stakeholder.

[spsneo]

@vihar - make copy modal also doesn't allow changing project.

[sargrapher]

I was able to duplicate an issue from one project to another project, but could not remove the original one.

gh issue edit 415 --add-project <new project>

These threw a error, but one did copy the issue to the new project:
gh issue edit 415 --remove-project <project>
gh issue edit 415 --add-project <new project> --remove-project <project>

The error was:
failed to update <github instance>/<project path>/issues/415: GraphQL: Could not resolve to a node with the global id of '' (delete_001)
failed to update 1 issue

I'm using GitHub Enterprise Server 3.13.6 and gh version (2.55.0)

[thomasborgen]

We would like this feature.

We like our projects to be "completable", so when it is done we don't add more to that project. Instead we use a bug report project. We then go through the issues in the bug project and assign them to either a specific Temporary (1-2 weeks of bug squashing) project or that the bugs were actually feature requests that should be added to a new feature project.

In the modal that we get after Right clicking an issue -> make copy, it was also not possible to change project.

[balabanov]

Upvote :)

[theparthacus]

to throw some light on why it's taken so long to ship moving work items from one project to another, the complexity of it lies in keeping backlinks alive and functional such that it wouldn't matter how many times you moved a work item and each time you clicked any link for that work item, you'd come to its current home.

behind the scenes, each time you moved a work item, we'd store the link for the project associated with that work item at the time of the move while generating a new link for the new project. irrespective of you doing this ten or fifteen or even a hundred times, the newest link would have to be backward compatible with all the previous links.

that is a non-trivial engineering problem, but it should come sometime in Q2 of this year.

@thomasborgen says,

In the modal that we get after Right clicking an issue -> make copy, it was also not possible to change project.

@spsneo says,

@vihar - make copy modal also doesn't allow changing project.

to answer this, i will take you back to the time when we brought Work Item Types. with that, you could have an entirely different set of properties over the default ones from one work item to the next. we could have show you a set of flags to map properties from one project to the next, but again, that's more complex than it sounds. so, temporarily, we had to stop editing of projects from anywhere after a work item had been created.

this, too, will be solved for soon.