Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

You cannot add a Parent link between work items #723

Closed
RoyalWulf opened this issue Mar 8, 2023 · 40 comments · Fixed by #871 or #917
Closed

You cannot add a Parent link between work items #723

RoyalWulf opened this issue Mar 8, 2023 · 40 comments · Fixed by #871 or #917
Assignees
@Alexander-Hjelm
Labels
bug Something isn't working

Comments

@RoyalWulf
Copy link

Describe the problem
Importing into Azure
Error:
[I][16:15:28] Processing 255/802 - wi '42275', jira 'ESERV-539, rev 3'.
[E][16:15:29] One or more errors occurred.
[E][16:15:29] TF201036: You cannot add a Parent link between work items 42275 and 42277 because a work item can have only one Parent link.
[W][16:15:29] ''ESERV-539', rev 3' - not all changes were saved.

ESERV-539 was a Task and changed to a sub-task of (42277) ESERV-551
but this didn't happen in Azure, in Azure 42275 has no parent

So, in Jira, fina state is 407 (Epic) has a link to Story 551 which has a link to sub task 539
In Azure 407has a link to 551 but 551 does not have a link to 539

The error reads like it has two parents, but i can't see that in Jira

To Reproduce
Steps to reproduce the behavior:
run
wi-import

Tool version

  • Version of the jira-azuredevops-migrator tool [e.g. 2.3.117]
    3.0.109

Attachments

Please attach the following files:

jira-export-log-230308-161030.txt

Screenshots
If applicable, add screenshots to help explain your problem.
@Alexander-Hjelm
Copy link
Collaborator

Looks like you have duplicate entries in your link map for Related, Duplicate and Child. Why? Try correcting your link map. See the config samples in the docs for examples.

    "link": [
      {
        "source": "Epic",
        "target": "System.LinkTypes.Hierarchy-Reverse"
    },
    {
        "source": "Parent",
        "target": "System.LinkTypes.Hierarchy-Reverse"
    },
    {
        "source": "Relates",
        "target": "System.LinkTypes.Related"
    },
    {
        "source": "Relates",
        "target": "System.LinkTypes.Related-Reverse"
    },
    {
        "source": "Duplicate",
        "target": "System.LinkTypes.Duplicate-Forward"
    },
    {
        "source": "Duplicate",
        "target": "System.LinkTypes.Duplicate-Reverse"
    },
    {
        "source": "Child",
        "target": "System.LinkTypes.Hierarchy-Forward"
    },
    {
        "source": "Child",
        "target": "System.LinkTypes.Hierarchy-Reverse"
    },
    {
        "source": "Blocks",
        "target": "System.LinkTypes.Dependency"
    }
]

@Alexander-Hjelm Alexander-Hjelm self-assigned this Mar 8, 2023
@RoyalWulf
Copy link
Author

Now on latest version: 3.0.115

Still get the error
config-agile-eServ1 json.txt
wi-import-log-230310-145608.txt

@Alexander-Hjelm
Copy link
Collaborator

@RoyalWulf Did you try and correct your link map? See my previous comment

@RoyalWulf
Copy link
Author

RoyalWulf commented Mar 11, 2023 •
edited
Loading

yes, see new config-agile-eServ1 json.txt file i attached above

@Alexander-Hjelm
Copy link
Collaborator

The way your config is set up now, it looks like it will complain if an issue has both a Parent and an Epic. So you will have to figure out a link structure that works for your migration, as Work Item in ADO cannot have two parents.

@RoyalWulf
Copy link
Author

I don't think the issue (ESERV-539) has an Epic and a parent.
It is a sub-task of ESERV-551, so it has a parent, but it does not have an Epic Link, infact Jira says a sub task can not have an Epic Link

@Alexander-Hjelm
Copy link
Collaborator

Sounds like it could be a bug then. Could you share the contents of ESERV-539.json? You may obfuscate any sensitive data of course!

@RoyalWulf
Copy link
Author

RoyalWulf commented Mar 22, 2023 •
edited
Loading

I have asked the business owner if I can send you the details.
I can see what has happened. Looking at the history it was a Task (which will have a link to an Epic) then became a sub-task with a link to a parent. Final state is a sub-task.
I have 2 examples of this in my current migration.

Will let you know more when my client gets back to me

@RoyalWulf
Copy link
Author

ESERV-539 - json.txt

@RoyalWulf
Copy link
Author

ESERV-415 - json.txt
This is the other example

@Alexander-Hjelm
Copy link
Collaborator

Alexander-Hjelm commented Mar 23, 2023 •
edited
Loading

For 539:

Looks like the following operations have been made, in historical order:

  • Parent link to ESERV-407 was added
  • Parent link to ESERV-551 was added
  • Parent link to ESERV-407 was removed

So it looks like there was a brief timeframe (< 100ms) where the issue had two parents.

@RoyalWulf I assume one of these parent items is an Epic Link and the other is a Parent. Do you know which one is which?

Also, do you know if the links were simply added/removed through the Jira GUI or somehow else?

I will relabel this as a bug.

To mitigate the issue, you could perhaps edit the offending work item json files and swap places between the links so that this:

    {
      "Author": "Romy Forrer",
      "Time": "2022-03-18T14:15:02.4+13:00",
      "Index": 3,
      "Fields": [],
      "Links": [
        {
          "Change": 0,
          "TargetOriginId": "ESERV-551",
          "TargetWiId": 0,
          "WiType": "System.LinkTypes.Hierarchy-Reverse"
        }
      ],
      "Attachments": [],
      "AttachmentReferences": false
    },
    {
      "Author": "Romy Forrer",
      "Time": "2022-03-18T14:15:02.427+13:00",
      "Index": 4,
      "Fields": [],
      "Links": [
        {
          "Change": 1,
          "TargetOriginId": "ESERV-407",
          "TargetWiId": 0,
          "WiType": "System.LinkTypes.Hierarchy-Reverse"
        }
      ],
      "Attachments": [],
      "AttachmentReferences": false
    },

Becomes something like this:

    {
      "Author": "Romy Forrer",
      "Time": "2022-03-18T14:15:02.4+13:00",
      "Index": 3,
      "Fields": [],
      "Links": [
        {
          "Change": 1,
          "TargetOriginId": "ESERV-407",
          "TargetWiId": 0,
          "WiType": "System.LinkTypes.Hierarchy-Reverse"
        }
      ],
      "Attachments": [],
      "AttachmentReferences": false
    },
    {
      "Author": "Romy Forrer",
      "Time": "2022-03-18T14:15:02.427+13:00",
      "Index": 4,
      "Fields": [],
      "Links": [
        {
          "Change": 0,
          "TargetOriginId": "ESERV-551",
          "TargetWiId": 0,
          "WiType": "System.LinkTypes.Hierarchy-Reverse"
        }
      ],
      "Attachments": [],
      "AttachmentReferences": false
    },

Then the links should be added in the proper order.

@Alexander-Hjelm Alexander-Hjelm added bug Something isn't working and removed support labels Mar 23, 2023
@RoyalWulf
Copy link
Author

ESERV-551 is the parent
ESERV-407 is the Epic
Your work around worked thank you

@Alexander-Hjelm
Copy link
Collaborator

@RoyalWulf perfect. We will keep the bug report open until we have resolved it :)

@RoyalWulf
Copy link
Author

Is this bug still not resolved?

@Alexander-Hjelm
Copy link
Collaborator

Alexander-Hjelm commented Jun 30, 2023 •
edited
Loading

We have not had the possibility of prioritizing this one yet unfortunately :)

@RoyalWulf
Copy link
Author

Pity, I have lots of these with the current migration

@Alexander-Hjelm
Copy link
Collaborator

Alexander-Hjelm commented Jul 3, 2023 •
edited
Loading

Note to self:

The solution is to ensure that the revisions are sorted based on UpdatedDate before they are exported.

I will focus on this one as soon as I have time. Likely during the summer vacations in july.

@Alexander-Hjelm Alexander-Hjelm mentioned this issue Jul 4, 2023
Closed
@Alexander-Hjelm
Copy link
Collaborator

JiraExport-bugfix_ensure-revisions-sorted.zip
@RoyalWulf , try this build of JiraExport and let me know if it solves your problem!

@RoyalWulf
Copy link
Author

RoyalWulf commented Jul 6, 2023 via email

@Alexander-Hjelm
Copy link
Collaborator

Simply run this one instead of you own JiraExport. You can use your own WIImport

@RoyalWulf
Copy link
Author

RoyalWulf commented Jul 10, 2023 via email

@RoyalWulf RoyalWulf mentioned this issue Jul 25, 2023
Open
@Alexander-Hjelm Alexander-Hjelm mentioned this issue Jul 28, 2023
Closed
@Alexander-Hjelm
Copy link
Collaborator

I managed to reproduce the following exception:

[I][09:10:52] Processing 45/150 - wi '210219', jira 'AGILEDEMO-15, rev 5'.
[E][09:10:53] One or more errors occurred.
[E][09:10:53] TF201036: You cannot add a Child link between work items 210219 and 210218 because a work item can have only one Parent link.

I will take a look at what is happening as soon as possible. I have a few other issues that need my attention first though :)

@Cookietogo97
Copy link

@Alexander-Hjelm I tried the fix you implemented but I still have the same error as the user that reported the bug.
[I][22:08:16] Processing 26770/27579 - wi '13454', jira 'KPL-1678, rev 12'. [W][22:08:16] '[Removed] KPL-1678/13454->DPPM-10/-1 [System.LinkTypes.Hierarchy-Reverse]' - target work item for Jira 'DPPM-10' is not yet created in Azure DevOps/TFS. [E][22:08:16] Mindestens ein Fehler ist aufgetreten. [E][22:08:16] TF201036: You cannot add a Parent link between work items 13454 and 13959 because a work item can have only one Parent link. [W][22:08:16] ''KPL-1678', rev 12' - not all changes were saved.

This is the revision where the issue first occurs:
{ "Author": "", "Time": "2023-08-17T11:36:35.11+02:00", "Index": 12, "Fields": [], "Links": [ { "Change": 1, "TargetOriginId": "DPPM-10", "TargetWiId": 0, "WiType": "System.LinkTypes.Hierarchy-Reverse" }, { "Change": 0, "TargetOriginId": "KPL-2220", "TargetWiId": 0, "WiType": "System.LinkTypes.Hierarchy-Reverse" } ], "Attachments": [], "AttachmentReferences": false }

Is it possible, that the error is caused by DPPM-10 not existing and therefore not really getting removed?

@Cookietogo97
Copy link

I should add that DPPM-10 does exist but the key was changed. By the time the error occurs it should be KPL-2081, but for some reason it is always called DPPM-10 in the revisions. I think that is the reason for the "not yet created" warning.

@Alexander-Hjelm
Copy link
Collaborator

@Cookietogo97 that could indeed be an issue. I have not yet had the time to look at this issue, but try and free up some time to work on a patch ASAP :)

@Alexander-Hjelm Alexander-Hjelm mentioned this issue Oct 3, 2023
Merged
@Alexander-Hjelm
Copy link
Collaborator

Alexander-Hjelm commented Oct 3, 2023 •
edited
Loading

Found a fix for my case, raised a PR fix here: #871

@Alexander-Hjelm
Copy link
Collaborator

Alexander-Hjelm commented Oct 3, 2023 •
edited
Loading

Anyone experiencing the issue, please try this build and let me know the results!
Debug.zip

@Alexander-Hjelm
Copy link
Collaborator

@RoyalWulf , @Cookietogo97, if either of you are still available and still experiencing the issue, give the above release a try and let me know if that solved it for you. At least for me the tool is now running correctly without any trace of the error.

I will merge the PR and close this issue if there is no reply within a reasonable time

@RoyalWulf
Copy link
Author

RoyalWulf commented Oct 4, 2023 via email

@Alexander-Hjelm
Copy link
Collaborator

Perfect, thx!

This fix only addresses the errors of the following sort:

You cannot add a Parent link between work items XXX and YYY because a work item can have only one Parent link.

Any other issues related to this ticket? I will try and go over the other open Bugs in the repo ASAP

@RoyalWulf
Copy link
Author

@Alexander-Hjelm This has not fixed my errors
wi-import-log-231006-143914.txt

What other files do you want to look at?

@Alexander-Hjelm
Copy link
Collaborator

Ok!

Look in the .json files for issues 79928 and 79929 and any other related issues that were involved in the link parent link/epic child link swaps. Do you see anything strange, like a link being removed before it is created, or anything simliar?

@Alexander-Hjelm
Copy link
Collaborator

Alexander-Hjelm commented Oct 6, 2023 •
edited
Loading

Otherwise send me the .json files for issues 79928 and 79929, plus any other issues that were ever related to either 79928 or
79929. You can try to reduce the number of issues to the smallest possible that still triggers the errors.

@RoyalWulf
Copy link
Author

RoyalWulf commented Oct 9, 2023 via email

@Alexander-Hjelm
Copy link
Collaborator

@RoyalWulf Is it still ESERV-539 and ESERV-415? Are there any other issues linked with either of these? If so, then please share those as well! Or have you confirmed that the problem occurs when importing both of the two above issues in isolation from any other data?

In my experience, the error seems to occur when there are 3 or more issues in a migration, and an Epic Child link is swapped from one target issue to another. Jira doesn't quite know what to do with the dates, and reports them in the wrong order.

@RoyalWulf
Copy link
Author

RoyalWulf commented Oct 9, 2023 via email

@RoyalWulf
Copy link
Author

RoyalWulf commented Oct 9, 2023 via email

@Alexander-Hjelm
Copy link
Collaborator

Ok, I hadn't considered that scenario actually. I will try and replicate that in our test enrivonment as soon as possible. In the meantime I will probably merge #871 since it fixes an issue that we are experiencing at another customer's migration

@Alexander-Hjelm
Copy link
Collaborator

Merged #871. Reopened after automatic close since the issue still persists.

@Alexander-Hjelm Alexander-Hjelm mentioned this issue Nov 27, 2023
Merged
@Alexander-Hjelm
Copy link
Collaborator

Closed issue with the completion of #917. Please reopen this issue and @ me if the problem persists.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Alexander-Hjelm Alexander-Hjelm

Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
3 participants
@Alexander-Hjelm @Cookietogo97 @RoyalWulf