Defect #12775
closed
Non-dictionary type custom field values lost when copying multiple issues
0%
Description
If copying multiple issues via the right click context menu, and there are custom fields, the content of the custom fields is lost in the destination issues.
Instead, I would have expected that the custom fields would be marked with (No change) in the initial display, and then properly copied per-issue.
Thank you.
Files
Related issues
Updated by Jean-Philippe Lang almost 12 years ago
- Resolution set to Cant reproduce
Works fine for me with 2.2. (no change) is selected by default and values are preserved.
Updated by Jean-Philippe Lang almost 12 years ago
- Subject changed from If copying multiple issues via the right click context menu, and there are custom fields, the original content of the custom fields is lost. to Custom fields lost when copying multiple issues
Updated by w brown almost 12 years ago
- File MultiIssueCopy.docx MultiIssueCopy.docx added
Thank you for the quick response.
Just to be sure we're in sync, I've enclosed a screenshot. Note that the custom field TC Expected Result is empty. I would expect (No change) to appear. If this is the scenario you tested, I guess I'll pull down and install 2.2.0, even though I did not see any notes about this kind of issue in the changelog.
Updated by Etienne Massip almost 12 years ago
- Subject changed from Custom fields lost when copying multiple issues to Non-dictionary type custom field values lost when copying multiple issues
Updated by Etienne Massip almost 12 years ago
- Status changed from New to Confirmed
- Target version set to Candidate for next major release
Not tried by myself.
Updated by Etienne Massip almost 12 years ago
- File bulk_copy_screen.png bulk_copy_screen.png added
- Description updated (diff)
Updated by Jean-Philippe Lang almost 12 years ago
- Status changed from Confirmed to New
I really can't reproduce with latest Redmine. The textarea is empty on the copy form indeed but the custom field value is actually preserved on the copied issue.
This behaviour is implemented in source:/tags/2.2.1/app/controllers/issues_controller.rb#L420 (blank values in parameters are considered as "no change" and are ignored).
Updated by Etienne Massip almost 12 years ago
I think that this issue is about user xp, I set status to Confirmed after seeing the screenshot, we understand that values are blanked.
Worse, the actual behavior also doesn't allow the user to erase the values of the text field (for example).
What would be the best explicit way to go? Add a No change checkbox before these fields, unchecking it would enable them for edition?
Updated by Daniel Felix almost 12 years ago
I like the solution with those checkbox. There should be a dependencie. If the checkbox is selected, no input-field should be displayed and the input field won't be respected in the save process.
If the checkbox is deselcted, the input field blinds in and could be edited.
Updated by Jean-Philippe Lang almost 12 years ago
- Status changed from New to Closed
- Resolution changed from Cant reproduce to Invalid
I think we should close this one as Invalid as this is the currently expected behaviour. Checkboxes would be a better solution, a discussion about this was started in #10363.
Updated by Etienne Massip almost 12 years ago
- Target version deleted (
Candidate for next major release)