Defect #20360
closedProject copy does not copy custom field settings
Added by Sebastian Paluch over 9 years ago. Updated over 9 years ago.
0%
Description
When making a project copy by going to /redmine/projects/template/copy custom field check boxes on the new project form are not set, all are unchecked. After project copy all custom field values are lost.
Files
project-copy.png (94.2 KB) project-copy.png | Sebastian Paluch, 2015-08-17 12:16 |
Related issues
Updated by Toshi MARUYAMA over 9 years ago
- Status changed from New to Needs feedback
I think this is expected behavior. What do you expect?
Updated by Sebastian Paluch over 9 years ago
- File project-copy.png project-copy.png added
No, this is not expected behavior. I do have a project setup and want to use it as template. I do have chosen what trackers and custom field I want to use. I do have some issues created that do have values in custom field.
When I make a project copy all previously chosen custom fields are not checked on the new project form, if I proceed with copy, custom fields are to setup correctly and values for issues are not copied at all.
I would expect custom fields to be pre-selected in the same way as trackers are. Take a look in attached picture. Project settings on the left, project copy form on the right. Trackers are checked correctly, custom fields are not.
To copy my project template I need to have to web browsers open and manually set custom fields in the same way as in project setting. This is not expected.
Updated by Laurent Breuillard over 9 years ago
- Copied to Defect #20559: Project copy does not copy custom field settings added
Updated by Toshi MARUYAMA over 9 years ago
- Affected version changed from 3.0.1 to 2.6.5
#20559 says 2.6.5 has same issue.
Updated by Toshi MARUYAMA over 9 years ago
- Copied to deleted (Defect #20559: Project copy does not copy custom field settings)
Updated by Toshi MARUYAMA over 9 years ago
- Has duplicate Defect #20559: Project copy does not copy custom field settings added
Updated by Toshi MARUYAMA over 9 years ago
- Status changed from Needs feedback to New
Updated by Toshi MARUYAMA over 9 years ago
- Category changed from Projects to Custom fields
Updated by Sebastian Paluch over 9 years ago
So, I tried to track it down and here are some observations.
The r1592 has changed how custom fields are handled.
In /app/views/projects/_form.html.erb a line determining if custom field checkbox should be checked has been changed to use @project.all_issue_custom_fields
. Today the code looks like this:
<%= check_box_tag 'project[issue_custom_field_ids][]', custom_field.id, (@project.all_issue_custom_fields.include? custom_field),
:disabled => (custom_field.is_for_all? ? "disabled" : nil),
:id => nil %>
It seems that when project is copied the @project.all_issue_custom_fields
returns nothing. The underlying SQL looks like this:
SELECT `custom_fields`.* FROM `custom_fields`
WHERE `custom_fields`.`type` IN ('IssueCustomField') AND
(is_for_all = 1 OR id IN (SELECT DISTINCT cfp.custom_field_id FROM custom_fields_projects cfp WHERE cfp.project_id = NULL))
ORDER BY `custom_fields`.`position` ASC
Notice that it checks for cfp.project_id = NULL
, this seems to be wrong and suggests that at the time when @project.all_issue_custom_fields
is called, the @project.id
is not set.
The r11916 has changed the @project.all_issue_custom_fields
to return a scope and include project id in WHERE causing the problem.
Updated by Jean-Philippe Lang over 9 years ago
- Status changed from New to Resolved
- Assignee set to Jean-Philippe Lang
- Target version set to 2.6.8
Thanks for pointing this out, fixed in r14618.
Updated by Jean-Philippe Lang over 9 years ago
- Status changed from Resolved to Closed
- Resolution set to Fixed