Bear with me, this one's a challenge to describe succinctly:
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!
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?
@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:
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?
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!
@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?
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.
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:
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:
@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:
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.
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.
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.
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:
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)
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! ;-)
Hello Community! I hope you've been enjoying the 🍂Apptoberfestivities🍂 (I know I have!) The event is heating up next week with a series of virtual events that we're calling the 🍻🍂Partner App ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events