|
[
Permlink
| « Hide
]
Kevin Wilson added a comment - 26/Oct/05 03:19 PM
This is as you state 'Major' since data integrity is lost during the consolidation of projects when issues are moved from one project to the next. I just noticed the 'retain' value does not work at all for fix/affected version values.
I think the priority on this bug should be "critical" since it causes data loss when an issue is moved in jira. This bug prevents us from merging our jira projects
Here's additional information in jira forum: This is really very critical due to the risk of loosing data and the impossibility of doing complex data migration taks from other systems.
And it is currently very critical for our current Bugzilla Migration project (customer project): We are currently doing the same kind of migration as described in http://forums.atlassian.com/thread.jspa?threadID=9557&tstart=0  . There we have to migrate from a multitude of Bugzilla products (which will be imported into a multitude of JIRA-projects) and other old JIRA-projects into one new structered JIRA project.
And for this migration task we have to move thousands of issues from the imported projects into a new project. There we really have no chance to do this manually for each component-version pairing since we have several houndred of this pairs. Is there no change to support us with at least a small patch for the bulk operation doing the right thing as pretended in the bulk operation with the 'retain' option for the component and version fields when the target project has the same values for components and for versions? (Which is in my point of view nothing than a bug because the bulk wizards is pretending this functionality and I've trusted all the time this feature for the migration project !) I really hope that you can provide us a small patch for this issue!? Thanks for the feedback guys.
I'm not sure if we're going to be able to give you a patch for this, but we'll certainly fix this up. We'll see if the change is too pervasive for 3.5.1 or not. If we can't get it done for 3.5.1 then we should at least disable the "Retain" checkbox for versions and components when moving between projects, since they are irrelevent and clearly misleading. After some further discussions, the change will require a change to the Field's interface
, which is quite a major change. So, unfortunately, this wil lhave to be done for 3.6 It's great to see this on the road map. I experimented with the Bulk Moving and found out it's practically impossible to gracefully merge projects.
When doing CSV Imports, I have the option to create missing components and versions. I think that'd be useful also when moving issues. When merging projects, the old data might make complete sense and if the only option to keep the data is to manually create all the components and versions in the target project, that'd be quite a hassle in most of our projects that I'm thinking of potentially merging. What I think could be ideal is that if I could map each component and version separately. In other words, as one step in the bulk move, list each component from the source project and let the user determine if he wants to map each component to some component in the target project (pulldown menu, if component with same name exists, preselect it) or create the component as part of the move. Same for versions. This way I couldn't lose any data as part of the move. Was just bitten by this again.
I had to merge 2 projects into another one. What could have been a 5 minute procedure now took me 2 hours as I had to bulk-move issues per component  Hopefully this'll make it into 3.7 I strongly agree with Sulka Haro and wish if I could map multiple issues to each component and version separately. His idea, if component with same name exists, preselect it and if not, create the component as part of the move, sounds great to me. I really wish you could consider providing this feature. We may possibly upgrade our jira if this comes true.
I want to add my vote as well as comment here because this missing feature "bites" us as well several times a month using the bulk move.
Unfortunately this wasn't scheduled for 3.7! I think this issue should be scheduled for the next release. Currently we are using 3.7.2 # 186, to which we migrated yesterday and were disappointed as this is even not resolved in the latest one
The retain checkbox checks for the component IDs. Rather, its better if it checks for the component name and then intimate the user about the same. Hope this is targetted for the next release. We are completely disappointed that the "retain"-option does not work for all the fields "component" and "fix / affects version".
This is not to an improvement but a real bug, isn't it? (and by the way an easy one to fix...) Please change to BUG or reopen the duplicated, linked issue! I was just about to file another duplicate of this.
Here is the offending page, which strongly suggests that the Components and Version fields will be retained:
Yes, this is a bug - a UI bug at the very least, since the page above is horribly misleading, and critical priority since it results in data loss. Just ran into this bug ourselves, resulting in a manual 1 by 1 manual move action to the new project (and nearly a complementairy RSI) .
Had to move all issues from one former project to a new one with other key name (due to project split), created an exact duplicate project B of Project A, all components, all versions. exactly identical project setup regarding permissions ect. The bulk move was unable to correlate the idential components and versions (no matter the retain checkmark). The frustrating part is that the manual move implemented for the per-issue does do this correctly, making that a [next], [OK],[Next] action. This is very frustrating. I have written a JIRA plugin which restores versions and components lost as a result of moves:
http://confluence.atlassian.com/display/JIRAEXT/Bulk+Move+Restore+Lost+Fields This should at least alleviate the pain until the problem is properly fixed. Regards, I tried this plug ( jira 3.10) but i ve got an error message. None of the issues are repaired.
KBVA-793 First, please not that other fields like Assignee get changed (Assignee gets changed to the bulk mover). Please make sure ALL fields are left as is unless selected otherwise or if the retain check-box is slected.
The plug-in worked great for me, except that it doesn't change back other fields like the Assignee as just mentioned. I also wanted to comment on the original question in the description in which options a), b), and c) are presented. I'm a little confused by the options offered. Let me suggest what I think should be done. If a field has something selected and the "Retain" box is unchecked, the selected value should be used. Otherwise, the old values should be transfered in the following maner: For each value selected in the originating bug, if there is a value in the target project with the same name, that one should be used. If not, create one with the same attributes (Name, Description, whatever) in the target project. Note that the multi-selected field case isn't special; each value selected should be created as needed in the target project. Carlos,
If the retain value checkbox is checked, the assignee should only get changed if the the user the issue is currently assigned to, is not assignable in the destination project. Is this not what you are seeing? If so, would you be able to create a support request on http://support.atlassian.com Cheers, My issue with the assignee turned out to be a permissions problem (user has to have the "Assignable User" permission). Once I put the right assignable users in the jira-developers group, it worked fine. See https://support.atlassian.com/browse/JSP-15806
for details. Carlos,
Thanks for the update. I am glad the problem is solved. Cheers, We have another support customer affected by this problem.
I wholeheartedly agree with Jeff that it is a bug. The user interface says that we are going to retain original values for versions and components, and then fails to do so. Any chance of us fixing it? New UI for retaining versions in JIRA 3.11.
Note that the user interface has been improved in JIRA 3.11 to indicate that issues that are not already in the destination project will not have their components or versions retained:
This addresses the user interface issue, but of course the underlying issue remains that versions and components are not retained. from SAC
I have verified that the Bulk Move Restore Lost Fields
plugin works for 3.12.1 (and presumably versions down to 3.10.1). From Suneetha (JSP-20265
):
Please work on this issue The plugin only works for the "fix version's" field but not for other user defined fields of the type "version picker" type like for example "found in version" and "approved in version".
When we want to move issues from one project to another we need 3 "version picker" fields to be updated. However the plugin works only for the "fix version's" field which is not enough for us. I see that there is no sollution planned for Jira 4.0. Do you have any idea when this issue will be solved or could the plugin be extended? Guh – so this issue still exists for 3.13.1?
@Darryl Lee
Yes this problem is still in 3.13.1 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Critical
Retain values checkbox for Bulk Move should preserve versions or components based on version and components names
