Project

General

Profile

Actions

Defect #30001

closed

CSV importer ignores shared version names of other projects

Added by Go MAEDA almost 6 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Normal
Category:
Importers
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Fixed
Affected version:

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

30001-34stable.patch (595 Bytes) 30001-34stable.patch Yuuki NARA, 2018-11-23 11:08
test_for_30001.patch (741 Bytes) test_for_30001.patch Marius BĂLTEANU, 2018-11-25 18:44
Actions #1

Updated by Yuuki NARA almost 6 years ago

+1

Actions #2

Updated by Yuuki NARA almost 6 years ago

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

Actions #3

Updated by Marius BĂLTEANU almost 6 years ago

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.

Actions #4

Updated by Go MAEDA almost 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.

Actions #5

Updated by Yuuki NARA almost 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.

Actions #6

Updated by Yuuki NARA almost 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.

Actions #7

Updated by Marius BĂLTEANU almost 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.

Actions #8

Updated by Yuuki NARA almost 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.

Actions #9

Updated by Go MAEDA almost 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
Actions #10

Updated by Marius BĂLTEANU almost 6 years ago

It is fine for me.

Actions #11

Updated by Jean-Philippe Lang almost 6 years ago

  • Status changed from Confirmed to Resolved
  • Assignee set to Jean-Philippe Lang
  • Resolution set to Fixed

Fix and test committed, thanks.

Actions #12

Updated by Jean-Philippe Lang almost 6 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF