Clone issue with quick action
Problem To Solve
When I'm creating a lot of issues, I want to quickly clone the meta data of one issue into the new issue i'm making, so that I don't have to manually add all the same meta data.
We currently have a
copy_meta data quick action, but it is clunky because it requires you to first create the new issue, copy the ID or path of the issue you want to copy meta data from, then use the quick action. Cloning would remove that clunky workflow.
- A new quick action called
/cloneand companion UI element, that you can use in an issue, if you have permissions to do so.
- When you initiate a clone, you first select which project you want to clone into, with the current project being the default.
- Once you confirm the target project, you are taken to the "New Issue" form in the target project with the meta data from the former issue already populated in the form. Meta data to initialize the form with:
- Due Date
- Iteration (needs to be added to the New Issue form)
- Health Status
/clonequick action supports an additional param
/clone [path]. If it is not present, the current project is used for the target. If it is set, the path is used for the target.
@hollyreynolds to add final UX
- We are proposing consolidating certain global issue actions into a combined drop down menu in the Issue header / sticky title (#233974). This would be a logical place for the "Clone" UI action to live.
Quick Action edge cases
- What happens if an issue is created programmatically with the
/clonequick action present? Given the
/clonejust initiates the workflow for cloning the issue, would we go ahead and create the issue in this instance since we can't redirect to a "New Issue" form?
Given the proposal, you would need to select a target project before going to the new issue form. Why don't we just put the target project field on the new issue form to begin with? Our current UX approach that requires users to navigate to a project before creating an issue is clunky and doesn't feel ideal. Given:
I should be able to select "New Issue" and select which project I want to create the issue within. This may be a separate issue, but if we did that first, it would make initiating a clone a bit more intuitive.
- Follow the same permissions model for roles that are able to create issues
- GitLab Core because being able to clone an Issue would not impact a purchasing decision by a buyer in one of our paid tiers.
- UI element to Clone an issue.
- Cloning is tied to the Issuable model so we can easily Clone Epics (#9398) and other objects that use the Issuable model.
- A bit of future proofing so when new attributes are added to Issuables, they are required to define whether or not they are clonable. If we make this an optional question to answer, it will most likely get overlooked during the initial implementation of the new attribute.
- Initiating clone redirects user to New Issue form with the specified meta data prepopulated.
- Pajamas First.
- GraphQL First.