|
[
Permalink
| « Hide
]
Scott Farquhar [Atlassian] added a comment - 09/Apr/03 09:21 AM
This is already enabled. Check that you have the 'move issue' permission turned on.
Move issue is not the same as copy issue. I believe there are many use cases for the copy action, for example: copy support request to a bug report, copy similar request to a new request in the same project etc.
That's correct, I originally aimed this issue to the problem that it really is not possibly to COPY issues, only the MOVE is possible.
What I want is e.g. to duplicate the issue for two different projects or assign the issue to two (or more) resources. We use cuncurrent engeneering, and thus have to solve the same defect in different versions. Possibility to copy a defect (with option to automaticly create a link between issues) to an open edit-form (for changing various options) will save us a lot of work!
If you can copy and issue you should be able to copy and issue but using a comment as the description.
Need to decide which is most relevant, or have different options to copy or create linked.
Added basic clone issue functionality for 2.7. Issues can be cloned within the smae project and are linked by properties file specified link name.
Modified summary of this issue to address the functionality of cloning issues between projects. This functionality would need to address the existence of unique fields, components specific to certain projects. At present, the basic clone feature clones within the same project.
Having a deep clone feature would also be very nice.
Todays cloning doesn't go very deep. it misses:
What does every one else think? Cloning between projects is very useful to us as well. Even if only basic information is cloned especially if link to the original issue would be created. Multiple projects use componenets that we develop. Every project and every component have corresponding jira project. Often component problem is reported in one of the projects. It has to be copied into component jira project. Currently we do it in 2 steps - clone, then move. Merging it into one cloning step will be very useful.
Copying (cloning) issues to another projects would be essential for our company, too. What we would like to see is sort of move-like operation (incl. selecting status, components, versions...) with possibility to link new issue to the original. Nice-to-have would be also to choose link type for this link relation.
In 3.4 we have added another extension point for JIRA. This will allow cusotmers to build their own Operations
 and have them available while viewing an issue. An example of this is the Google this issue plugin. The extension point was created so things like this issue could be implemented by customers with out hacking the source code. Cheers, I would like to a bulk copy of severaly issues at once instead currently having to clone and move. this is very tedious when you want to copy multiple issues to a new project.
My bad. This is exactly the feature we need.
Martin,
I am not sure what you mean by 'call the clone/move operation'. It is possible to manually clone an issue and then move it. If you are trying to customise JIRA, please e-mail jira-support@atlassian.com Thanks, I am not quite sure that this feature is really 'hacking' the source code. Just need to support (bulk) Copy/Clone cross-project and not forget any bits during the copy, with the possibility to leave a link to the way-back originatingissue report. Do we really have to write our own utility to do this? Seems dodgy to muck with that.
There appears to be a reasonably large level of interest in this feature...
That doesn't help for several reasons. For one thing, it creates an "Issue Created" event in the wrong project, notifying everyone in project A about an issue that is only to be created in project B. While we love JIRA's email notifications, many complain about the volume, so adding one that we don't want people to see if even more noise. We create far too many software products to use a project per product similar to Atlassian's own usage for Jira, Confluence, Crowd, etc. Instead, we use multiple business unit projects (think support, marketing, engineering, development, QA) and currently shunt tickets around between projects in high volumes.
Before Scott or anyone else asks, we'd prefer not to implement less projects because these represent business units and require their own workflows, field schemes, administration and so on. We also don't want task type proliferation, which is an artifact of collapsing projects into a single project if you want to implement these things. The project metaphor works well for us, where a project maps to a business unit. That is, we take a business unit centric, not issue centric, view of ticket accountability. Although efficient, this is problematic because the lifecycle of a given issue will see it move between many, if not all, of these projects. As a result, we can't get reasonable stats like created/resolved and so on - charting plugin style stats - because an issue will open in one project and frequently close in another. By extension, we also can't do accurate reporting or searching per business unit since we lose visibility of issues when they transition between projects. An obvious possible solution is ticket proliferation; that is, when the support dept determines they want to escalate a ticket to engineering, for example, they create a new engineering ticket and relate it to the original.
So, as a result, we simply can't implement this and live with useless statistics instead. "Clone in new project" would provide an expedient way to enable us to have tickets that live their entire cycle in one project, spawning tickets in others as necessary, with automatic cloned relationships to the originating tickets. So, ++++1 from us on this ticket. Note: My view on this is that this is still a workaround. Ideally, Project is just an abstraction, not a container. It would be coolest if an issue could optionally be included in a project search if it has ever been associated with that project. Almost like the multiply selectable component field, or perhaps more simply a cumulative tag field. Would welcome any suggestions as to how we could achieve this with custom code; right now I see this as the biggest management (as opposed to technical or functional) issue in Jira. Have you tried the Clone and Move plugin
? This feature is absolutely vital for efficient bug management. In a Product-Project software configuration management model, it is very vital to copy or clone bugs from one codeline to another.
However, while copying the destination issue should have: Status=Open, Unassigned, Link back to the original issue. Status & Assignee SHOULD NOT be carried forward to the destination issue, as destination issue will most probably have its own life cycle and resources working on it. Cloning issues in a Project-Project sw config management
One of the use cases is a work flow screen for a Help Desk application. If the issue in the help desk turns out to be a enhance, feature request, or bug report (vs just help), then there should be an easy way to clone and move the issue from the Help Desk project to a programming project.
This works for the Attachment Field, so I don't know why this can't also be added to a workflow screen. Clone between projects (or Clone / link / move). We need this functionality in an effort to design around security requirement and ITIL v3 compliance. Oh joy.
Hugely important to me. I have two code streams, one being the stable flagship product, and the other being the new-to-market feature-rich version. Each of these is a project. As the core code is shared between the two, the ability to clone issues between them is vital.
I'm trying to deploy jira widely within my company. This is one of the first requests. I see that clone and move is present so I'll have them do that for now, but I'm sure a one step process with optional linking would be well received.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Reopened
Major
Clone Issues between projects
