Feature #28198

Support issue relations when importing issues

Added by Gregor Schmidt over 2 years ago. Updated 3 months ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:Go MAEDA% Done:

0%

Category:Importers
Target version:4.2.0
Resolution:Fixed

Description

As promised in #22701, I now would like to propose a patch, which adds handling of issue relations to the CSV importer.

Usage

The attached patch extends the import configuration view with a new block, so that users may select a column for each relation type. The parent issue field also moved to the new block, since it's conceptually related.

Within the CSV file the columns may define multiple relations of the same type, each separated with ,. Related issues follow the same rules as parent issues. A string preceded with a # is supposed to be an existing issue. Without the # it's supposed to be another row within the import file. For follows and precedes relations an additional delay may be present, e.g. #12 3d specifying a relation to issue #12 and a delay of 3 days.

Technical notes

Since issue relations may only be created when the issue was already saved, I've added a second step to the import. Additionally to build_object, which needs to be implemented by Import sub classes, there's also a extend_object method now. This is used by the IssueImporter to save the relations after the issue was already saved successfully.

Additional considerations

Initially, I wanted to build the import, so that issue relations exported from Redmine could be imported directly. But the format that's used by the exporter was designed for humans, not so much for computers. Most importantly, to parse this format we would need to grep for the localized relation names, which might even change between versions of Redmine. Therefore I settled for the proposed approach of having separate columns for each relation type.

0001-Support-issue-relations-when-importing-issues.patch Magnifier (16.2 KB) Gregor Schmidt, 2018-02-16 13:02

0002-Support-issue-relations-when-importing-issues.patch Magnifier - Patch on top of #28213 (19.8 KB) Gregor Schmidt, 2018-02-19 14:35

issue_relations.png (80 KB) Marius BALTEANU, 2020-05-03 15:40

0002-Fix-failing-test.patch Magnifier (3.32 KB) Marius BALTEANU, 2020-05-03 15:53

0001-Rebased-patch-from-28198.patch Magnifier (19.8 KB) Marius BALTEANU, 2020-05-03 15:53


Related issues

Related to Redmine - Feature #22701: Allow forward reference to parent when importing issues Closed
Related to Redmine - Feature #28213: Support external ID when importing issues Closed
Duplicated by Redmine - Feature #33330: Import of issue relations when imported from csv Closed

Associated revisions

Revision 19753
Added by Go MAEDA 3 months ago

Support issue relations when importing issues (#28198).

Patch by Gregor Schmidt and Marius BALTEANU.

Revision 19754
Added by Go MAEDA 3 months ago

Update locales (#28198).

History

#1 Updated by Gregor Schmidt over 2 years ago

This issue is in conflict with #28213. Since I would like to see both being applied, here's a patch for this issue applied on top of #28213

#2 Updated by Mischa The Evil over 2 years ago

  • Related to Feature #22701: Allow forward reference to parent when importing issues added

#3 Updated by Mischa The Evil over 2 years ago

  • Related to Feature #28213: Support external ID when importing issues added

#4 Updated by Mischa The Evil over 2 years ago

  • Target version set to Unplanned backlogs

#5 Updated by Go MAEDA over 1 year ago

  • Target version changed from Unplanned backlogs to Candidate for next major release

#6 Updated by Marius BALTEANU 4 months ago

  • Duplicated by Feature #33330: Import of issue relations when imported from csv added

#7 Updated by Marius BALTEANU 4 months ago

  • Assignee set to Marius BALTEANU

#8 Updated by Go MAEDA 4 months ago

  • Target version changed from Candidate for next major release to 4.2.0

Setting the target version to 4.2.0.

#9 Updated by Go MAEDA 4 months ago

  • Target version changed from 4.2.0 to Candidate for next major release

Go MAEDA wrote:

Setting the target version to 4.2.0.

Sorry, I have changed the target version mistakenly.

#10 Updated by Marius BALTEANU 3 months ago

I've updated the patch posted by Greg to apply cleanly on the current trunk and to fix all Rubocop warnings.

Additionally, I'm adding a new patch (0002-Fix-failing-test.patch) that fixes a failing test (test_parent_and_follows_relation) by updating the test assertions. From my checks, assertions were wrong in the initial patch because the start/due dates change after the follows relations are applied. I've double check the test expectations by reproducing the test from UI. A double check were is welcome.

Also, the initial patch:
  • adds a new section in the UI named "Issue relations" which is collapsed by default
  • moves the fields Unique ID and Parent task under this section along with the relation type fields. I'm not sure if it's the best idea to move those two fields as well.

All tests pass: https://gitlab.com/redmine-org/redmine/pipelines/142141722

I'll add the patch for auto-mapping fields after we integrate this one.

#11 Updated by Go MAEDA 3 months ago

  • Status changed from New to Closed
  • Assignee set to Go MAEDA
  • Resolution set to Fixed

Committed the patch. Thank you for this good improvement.

#12 Updated by Go MAEDA 3 months ago

  • Category changed from Issues to Importers

#13 Updated by Marius BALTEANU 3 months ago

Is it ok to leave the Unique ID and Parents task fields under the "Issue relations" section?

#14 Updated by Go MAEDA 3 months ago

Marius BALTEANU wrote:

Is it ok to leave the Unique ID and Parents task fields under the "Issue relations" section?

I noticed that but I thought that those fields can be said as "relations". Personally, I don't mind those fields being categorized as "Issue relations", but it could possibly confuse existing users.

Which do you think better? I am OK with either.

#15 Updated by Marius BALTEANU 3 months ago

Go MAEDA wrote:

I noticed that but I thought that those fields can be said as "relations". Personally, I don't mind those fields being categorized as "Issue relations", but it could possibly confuse existing users.

Which do you think better? I am OK with either.

I'm in the same case as you, not knowing which option is better. Maybe we receive a 3rd opinion on this.

Also available in: Atom PDF