Syncing issues between distinct projects including parent-child relationships

[Rick Crow]

Bear with me, this one's a challenge to describe succinctly:

• Note: This is a Jira Software Server instance

I have two projects with which I need to keep a subset of issues from the triggering project in sync with the target project. The triggering project uses basic issues and subtasks whereas the target project uses a number of issue types related hierarchically for use with Advanced Roadmaps.

My goal is to clone the parent issue and its subtasks from the triggering project to the target project (no problem there), create links between the clones (no problem there) and also create the appropriate parent link between the cloned issues in the target project. That's where I'm running into a roadblock. I have the related links between the 'peer' issues in both projects, but can't determine how to populate the Parent Link field for the child task in the target project to its parent, which would be a peer to the parent issue in the triggering project.

One additional comment; the child tasks in the triggering project are rarely created near the time its parent task is created, so there's no option to use anything that relies on time proximity.

Here's a diagram ... hope it helps:

And here's what I have so far for the creation of the child task clone (Rule 2):

Thanks in advance for any help!

@John Funk, @Simmo : any thoughts?

[Rick Crow · Accepted solution]

{    "fields":
      {    "customfield_21241":"{{issue.parent.issuelinks.last.outwardIssue.key}}"
      }
}

[Simmo]

Heya @Rick Crow ,

So, I am mostly following you. I'd just like to understand where your difficulty lies. Is it in the technical ability to actually set the Parent Link used by Roadmaps in Automation or is it the ability to link the child to the correct parent?

Cheers,

Simeon.

[Rick Crow]

@Simmo : The latter. I know how to set the value of the Parent Link field, but I can't determine how to source the issue key for the appropriate parent in the target project.

[Simmo]

I thought as much. You have two separate rules that create the child and paren issues yeah?

At different times?

[Simmo]

And which way do you need to do it? From the child to the parent I am assuming?

[Rick Crow]

Yes, two separate rules that clone the parent and subtask issues from the trigger project. Link from the child to the parent ... yes.

[Simmo]

Hehe, this is a real curly one. One last question. Which rule fires first? Parent or sub task one?

I might have a solution...

[Simmo]

@Rick Crow , I'll run you through my idea. It is complicated but it might give you some ideas.

Starting with your parent rule

I'm assuming your parent rule is fairly similar to the child one above. So, firstly, don't use the current issue branch. Do everything on the mainline.

Now, after you have cloned and linked the new ticket, we want to use the Set Entity Properties action like so:

This will set the key of the cloned parent onto the current issue (the one that was cloned).

Next, your sub task rule

We can now reference that key with the smart value:

{{issue.properties.clonedParent}}

So, when you do the clone action you should be able to set the parent link field to that value hopefully.

A bit crazy but see if that helps?

[Rick Crow]

Parent ... by definition! 😎🤞🏻

[Rick Crow]

I’ll take a look first thing tomorrow ... crossing my fingers!

Thanks!

[Simmo]

No worries. I think you're going to have to take this kind of approach.

If that doesn't work then you might then have to set this as an entity property on that cloned child and let another rule take over? 

But this sort of direction is how you'd solve it.

Best of luck!

[Rick Crow]

@Simmo : given I'm trying to link the cloned subtask (with the result not being a subtask) to an issue that is NOT the parent of the original subtask, but rather the result of the earlier cloning of the original parent issue ... don't I need the issue key from the link of the original parent rather than the key from the cloned parent itself?

[Rick Crow]

I've added labels to the diagram above to help clarify: The first thing that happens is that a new parent issue (A) is created in the triggering project. That gets cloned (B) into the target project and a link is created between them. This all happens in a separate automation prior to the solution I'm working on now.

For this automation, when a subtask (C) is added to the original parent task (A), I'm cloning C into the target project resulting in a new task (D). My open goal then is to connect D to B using the Parent Link field in D.

[Rick Crow]

Update: I can successfully get the issue key from A when setting values in D if I use a standard issue field such as Description. Here's the smart value I'm using:

{{issue.parent.issuelinks.last.inwardIssue.key}}

Now I need to get that same value into the Parent Link field. But when I try to set it using the following, the rule successfully runs with no errors, but nothing is written to the Parent Link field in D:

{   "fields":

     {      "customfield_21241":"{{issue.parent.issuelinks.last.outwardIssue.key}}"
     }
}

[Rick Crow]

@Andreas Knecht : Copying you as I found a post where you suggested the above parent link syntax as valid ... at least at the time. ;-)

[Rick Crow]

@Simmo : well ... not sure exactly what changed, but after a bit more mucking about, it's working! Here's the rule ... which is the same as above that, at the time, wasn't working:

{    "fields":
      {    "customfield_21241":"{{issue.parent.issuelinks.last.outwardIssue.key}}"
      }
}

I've created and used a new link type to ensure that I wouldn't get any unintended linking and maybe that's the key in that it's possible it was working before but was targeting the wrong issue(s) for the Parent Link. I'll go take a look and see if I can find issues that mistakenly have unexpected Parent Link information, but that's probably a stretch.

[Simmo]

I'll be honest, I'm not completely following but I haven't used Roadmaps. I think maybe you also didn't follow me either.

But if you've got a working solution thats a win :)

[Jan Dewald]

Hello Rick,

without diving into the details and also not knowing the new Roadmap feature (apologies), cloning always feels kind of cumbersome.

Is there a problem using only one project with the workflow configured for the desired results and using boards to fulfill individual needs? Maybe too many issues?

Also, stating the use case helps a lot.

Kind regards,

Jan

[Rick Crow]

Jan, thanks for the thoughts. The two projects and Advanced Roadmaps (Portfolio for Jira) are requirements. The triggering projects is a corporately-managed/owned project with a particular focus while the target project is for IT planning purposes. Having the ability to change what we need when needed is critical, and we can't do that in the corporately-owned project. There's a lot of history behind years of attempting to use a single project to satisfy both sets of needs, but after trying a number of approaches, I just had to admit defeat and move on!

Really, the Advanced Roadmaps element isn't much of a complication ... I included that information primarily to cover why the hierarchies don't match. Really, it's just a field that needs an issue number.

Thanks again!

[Jan Dewald]

Hi Rick, I can´t pinpoint it without taking a look at your configurations and also I´m having a blind spot regarding the roadmap feature (which is pretty much 100% a thing of filtering as a scope definition). Maybe there is a governance question involved as well.

But intuitively, I´m very sure there is a much more convenient solution to the problem.

This is what I hear, somewhat:

• Use Case:
  • The IT-Roadmap has to include a certain scope coming from source XYZ (which is, btw, on the same instance?) with the related data being updated in real-time
• Current approach:
  • Newly created and updated issues from a project A with special characteristics (information populated in certain fields for example) appear in another project B, providing data to the IT-Roadmap
  • The IT-Roadmap view requires certain issue links so that these items work correctly within the structure rules of your roadmap configuration (whether this is the roadmap feature from Atlassian or any other plugin that does this job)
  • (If on the same instance) The roadmap is using project B because view permission for project A is not granted to the owners of the IT-Roadmap

Is that the right direction? If so, your Jira administration should create permission that operates on issue-level and that complies with the data security rules of the owners of project A. This is something that can be done automated but must happen on their side. You would then simply widen the scope definition of your roadmap, including those issues.

Challenges from that point of view look a bit different then:

- the issues have another type and also, tasks from project A must be sub-tasks in project B

- the link type does not fit the structure rule

- add the link type from project A as additional structure rule - I don't know if Advanced Roadmaps is capable of that, but I know a plugin that can do that - But it would require a change of your roadmap tool)

Kind regards!

[Rick Crow]

Jan, thanks again for the thoughts. Unfortunately, it's not an option to simply include the corporate project issues within the same roadmap plan. Initially, that was my approach, but those involved in managing the corporate project weren't able to catch the vision, etc., so I moved on. Since moving on, I've actually decided, that for our purposes, it's probably for the best as, with our own copies of the issues, we can modify the elements we need to, include some child issues, exclude others that don't impact our deliverables, etc. ... and do what-if scenarios with the ability to mass manage changes as desired. So, for governance, scope, and tool usage purposes it's, unfortunately, an untenable approach. Things would be a little simpler if I could get the corporate project to simply change their issue type usage ... and we've discussed that ... but to this point, it's not happened, and I suspect won't for some time, if ever. But even if they did, I believe the other issues mentioned would still preclude that approach.

Without that option, I believe my current approach is valid, and I suspect there's a way to accomplish the last piece of my automation with a bit more digging into the Automation toolset. Plus ... I like a challenge! ;-)