Vote #79146
完了Support issue relations when importing issues
0%
説明
As promised in #22701, I now would like to propose a patch, which adds handling of issue relations to the CSV importer.
h3. 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.
h3. 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.
h3. 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.
journals
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
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Setting the target version to 4.2.0.
--------------------------------------------------------------------------------
Go MAEDA wrote:
> Setting the target version to 4.2.0.
Sorry, I have changed the target version mistakenly.
--------------------------------------------------------------------------------
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.
!issue_relations.png!
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.
--------------------------------------------------------------------------------
Committed the patch. Thank you for this good improvement.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Is it ok to leave the Unique ID and Parents task fields under the "Issue relations" section?
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
Would you be able to update the "HowTo import issues" wiki with information on how this works, please? I'm having trouble getting it to work.
[[HowTo_import_issues]]
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
related_issues
relates,Closed,22701,Allow forward reference to parent when importing issues
relates,Closed,28213,Support external ID when importing issues
relates,Closed,35656,When importing issue relations, the validation messages are not shown in the UI
duplicates,Closed,33330,Import of issue relations when imported from csv