Defect #11803
closed
When copying a project, issues are not copied
0%
Description
I downloaded and installed the lastest Bitnami Redmine, 'bitnami-redmine-2.0.3-1-windows-installer-r01.exe' (I think it's using Redmine 2.0.3 and ruby 1.8). When I copy a project,
I select this:
----
Copy
Members (1)
Versions (4)
Issue categories (0)
Issues (8)
Custom queries (0)
Forums (0)
Wiki pages (0)
----
however, the members and version etc are copied but not the issues, i.e. the issues from the original project are not copied into the new project.
I also looked at the production.log file, and see the message,
"Project#copy_issues: issue #300 could not be copied: ..."
then I locate the code in the project.rb file,
------------
def copy_issues(project)
...
if new_issue.new_record?
logger.info "Project#copy_issues: issue ##{issue.id} could not be copied: #{new_issue.errors.full_messages}" if logger && logger.info
else
issues_map[issue.id] = new_issue unless new_issue.new_record?
end
...
---------------
but I couldn't figure it out. Seems setting new_issue.new_record to true gives an error.
I also look at ChangeLog from 0.8 to 2.0.3, didn't find about this, is this functionality already implemented in the latest Redmine?
By the way, is there an wasy way to change Bitnami Redmine from production to development mode so I don't have to restart the service (could take couple minutes) everytime I modify some code to debug it.
Look forward your help, thanks much for your help and advice!
=======
See also:
Defect #10450
« Copy project Issues not working »
Added by Mario Luzeiro 6 months ago
Related issues
Updated by Jean-Philippe Lang about 12 years ago
Xiaochuan Lin wrote:
I also looked at the production.log file, and see the message,
"Project#copy_issues: issue #300 could not be copied: ..."
Could you past the actual full error message? That would be highly helpfull I guess.
Updated by Xiaochuan Lin about 12 years ago
Pasted in the following is a portion of the log information from the production.log file containing the actual full error message.
-----------------
...
Started POST "/redmine/projects/proj1/copy" for 127.0.0.1 at Wed Sep 12 10:41:51 +0800 2012
Processing by ProjectsController#copy as HTML
Parameters: {"utf8"=>"✓", "project"=>{"description"=>"", "tracker_ids"=>["1", "2", "3", ""], "parent_id"=>"", "identifier"=>"b", "name"=>"b", "issue_custom_field_ids"=>[""], "is_public"=>"1", "homepage"=>"", "enabled_module_names"=>["issue_tracking", "time_tracking", "news", "documents", "files", "wiki", "repository", "boards", "calendar", "gantt", ""]}, "only"=>["members", "versions", "issue_categories", "issues", "queries", "boards", "wiki", ""], "authenticity_token"=>"cfewI39ZPUH1m3cFHmx3Le3ITw9WZ2HJv/GJ4wi9oHs=", "commit"=>"Copy", "id"=>"proj1"}
Project#copy_issues: issue #1 could not be copied: customField1 can't be blankcustomField2 can't be blankcustomField3 can't be blank
Project#copy_issues: issue #2 could not be copied: customField1 can't be blankcustomField2 can't be blankcustomField3 can't be blank
Redirected to http://yfhdf-1/redmine/projects/b/settings
Completed 302 Found in 13279ms (ActiveRecord: 661.0ms)
...
-----------------
I just find that if I either set a default value or uncheck the 'Required' property of the custom field in the Administration page of Custom fields, the issues would be copied to the new project, however, the value of the custom field in the copied issue in the new project would be either the preset default value or blank accordingly.
Look forward your help, thanks much for your help and advice!
Updated by Jean-Philippe Lang about 12 years ago
- Status changed from New to Closed
- Resolution set to Invalid
Seems to be the expected behaviour, thanks for the feedback.
Updated by Xiaochuan Lin about 12 years ago
, i.e. the actual value of the custom field in the issues from the original project are not copied into the issues in the new project.
So, would this feature be included in a list of features to implement in the future version? thanks much for the help.
Updated by Xiaochuan Lin about 12 years ago
- Status changed from Closed to Reopened
Updated by Jean-Philippe Lang about 12 years ago
- Status changed from Reopened to Closed
Xiaochuan Lin wrote:
So, would this feature be included in a list of features to implement in the future version? thanks much for the help.
No, you just can't copy these issues because they have invalid custom field values. After a custom field is made required, an issue with a blank value for this field can not be created.
Updated by Yiheng Lu almost 12 years ago
Jean-Philippe Lang wrote:
Xiaochuan Lin wrote:
So, would this feature be included in a list of features to implement in the future version? thanks much for the help.
No, you just can't copy these issues because they have invalid custom field values. After a custom field is made required, an issue with a blank value for this field can not be created.
Hi Jean,
I'm facing the same issue. Just that even if i set the issue required custom field to a valid value, it still failed to copy over. (in fact, it is Ok if copy just this issue. But if copy the whole project, this issue will not be copied as log report "issue could not be copied: xxxx can't be blank". But it's not blank and already set a valid value in the source issue.)
Updated by Rick Hunnicutt almost 12 years ago
I am having the same issue. The custom field is not blank in the original issues but will not copy with the error that it can't be blank. I assume this is because there is no default value for the custom field. This is not resolved in any way.