Defect #30001
closedCSV importer ignores shared version names of other projects
0%
Description
When importing issues from CSV, you cannot set a target version for an issue if the specified version name in the CSV is a shared version of another project.
This issue was reported to redmine.tokyo community.
Files
Updated by Yuuki NARA about 6 years ago
- File 30001-34stable.patch 30001-34stable.patch added
I think that this defect can be addressed by correcting the following points.
app/models/issue_import.rb
def build_object(row, item)
- if version = issue.project.versions.named(version_name).first
+ if version = issue.project.shared_versions.named(version_name).first
I made patch for 3.4-stable for Revision 17627
Updated by Marius BĂLTEANU about 6 years ago
- File test_for_30001.patch test_for_30001.patch added
- Status changed from New to Confirmed
- Target version set to 3.4.7
Thanks Yuuki Nara for the patch, I can confirm that it works ok.
I'm attaching a unit test for this case, I think we can fix this issue in 3.4.7.
Updated by Go MAEDA about 6 years ago
I am in favor of this fix but my only concern is that the case when the current project and another project have versions with the same name. In that case, I think it is the natural behavior to pick the version in the current project. Probably a user may be confused if the version is picked.
Do you know how the patch handles that case? I have not deeply checked the current patch.
Updated by Yuuki NARA about 6 years ago
Thanks Marius BALTEANU for the unit test code.
Do you know how the patch handles that case? I have not deeply checked the current patch.
It is defined in the following place.
model/project.rb
def shared_versions
I pulled out the relevant part.
It is not designed to output version definition of own PJ first.
@shared_versions ||= begin
r = root? ? self : root
Version.
joins(:project).
preload(:project).
where("#{Project.table_name}.id = #{id}" +
" OR (#{Project.table_name}.status <> #{Project::STATUS_ARCHIVED} AND (" +
" #{Version.table_name}.sharing = 'system'" +
" OR (#{Project.table_name}.lft >= #{r.lft} AND #{Project.table_name}.rgt <= #{r.rgt} AND #{Version.table_name}.sharing = 'tree')" +
" OR (#{Project.table_name}.lft < #{lft} AND #{Project.table_name}.rgt > #{rgt} AND #{Version.table_name}.sharing IN ('hierarchy', 'descendants'))" +
" OR (#{Project.table_name}.lft > #{lft} AND #{Project.table_name}.rgt < #{rgt} AND #{Version.table_name}.sharing = 'hierarchy')" +
"))")
end
Actually, in the hierarchical structure project, we defined version by sharing and displayed choices of fixed version.
Did not initially display the version defined in project.
Even with the CSV import function, if there is a version with the same name in the project hierarchy, I think that other than the self PJ will be selected.
Measures
In the process of shared_version, first output its own PJ, then exclude its own PJ when adding hierarchical structure.
Or declare which is output to the behavior when the same version name is defined as undefined.
If you define the same version name, you can not identify which version is defined in any PJ except when editing the ticket.
From this, it is considered inappropriate to define the same version name when sharing in the PJ hierarchy.
Updated by Yuuki NARA about 6 years ago
When using the project hierarchical relationship, it is difficult to intentionally set the same version name between projects.
It only leads to confusion.
When the same project name is defined, it seems mostly a mistake.
Updated by Marius BĂLTEANU about 6 years ago
I don't think that will be so many cases where the users want to import issues and will have versions with the same name. I'm in favour of fixing the current issue and discuss the fix for the second case (versions with the same name) in another ticket.
Updated by Yuuki NARA about 6 years ago
I agree with dealing with the issue of version display order when using the project hierarchical structure as a separate ticket.
The cause of this problem (in the CSV import function) is that the display order of the version choices for each project is not determined when using the version project hierarchy.
(Sometimes versions other than your own project are displayed first)
On the issue editing screen, I think that it is unnatural for users to not display their own projects as a choice of version first, which is very important.
It is difficult to intentionally use the same version name in the project hierarchy.
(There is a high possibility of erroneous setting)
However, I think it is necessary to clarify this problem as a known limit.
Updated by Go MAEDA about 6 years ago
What do you all think about the following implementation? It picks the version in the current project first when there are versions with the same name.
diff --git a/app/models/issue_import.rb b/app/models/issue_import.rb
index ad04c0be5..9fc4f5550 100644
--- a/app/models/issue_import.rb
+++ b/app/models/issue_import.rb
@@ -122,7 +122,10 @@ class IssueImport < Import
end
end
if issue.project && version_name = row_value(row, 'fixed_version')
- if version = issue.project.versions.named(version_name).first
+ version =
+ issue.project.versions.named(version_name).first ||
+ issue.project.shared_versions.named(version_name).first
+ if version
attributes['fixed_version_id'] = version.id
elsif create_versions?
version = issue.project.versions.build
Updated by Jean-Philippe Lang about 6 years ago
- Status changed from Confirmed to Resolved
- Assignee set to Jean-Philippe Lang
- Resolution set to Fixed
Fix and test committed, thanks.
Updated by Jean-Philippe Lang about 6 years ago
- Status changed from Resolved to Closed