Non-dictionary type custom field values lost when copying multiple issues
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.
#3 Updated by w brown almost 9 years ago
- File 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.
#7 Updated by Jean-Philippe Lang almost 9 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).
#9 Updated by Etienne Massip almost 9 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?
#10 Updated by Daniel Felix almost 9 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.
#11 Updated by Jean-Philippe Lang almost 9 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.