Defect #12775
closed
Non-dictionary type custom field values lost when copying multiple issues
Added by w brown almost 12 years ago.
Updated almost 12 years ago.
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
- Resolution set to Cant reproduce
Works fine for me with 2.2. (no change) is selected by default and values are preserved.
- 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
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.
- Subject changed from Custom fields lost when copying multiple issues to Non-dictionary type custom field values lost when copying multiple issues
- Status changed from New to Confirmed
- Target version set to Candidate for next major release
- 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).
- Description updated (diff)
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?
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.
- 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.
- Target version deleted (
Candidate for next major release)
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by