Parent assignee auto-assigned to children upon linking - can't make this rule work

[Aiste Marija Aidukaite-Urbanovic]

Hi! I've been trying to build a rule that would let me automatically copy the assignee from the parent issue. But it doesn't work, and for the life of me, I have no idea why. Currently, for testing purposes, I've built it so that the trigger is manual. ATSV3-1 is my parent issue, which has an assignee, and ATSV3-8 is the child issue, which has a parent and no assignee, that I'm trying to get to copy the assignee from the parent via automation. I'm running the rule from the ATSV3-8. I'm attaching a few screenshots. I'm using the cloud version of Jira Service Management. And yes, I'm using Edit issue fields action - Assignee > Copy from parent. Hope someone here can give me some guidance. Ty   

[Calvin · Accepted solution]

I may be misunderstanding here, but I don't see why you need the branch at all? In ATSV3-8, just use "edit issue field" that you have, pick the assignee value, and "Copy Assignee from Parent".

At the moment, it looks like your jumping into the parent ticket, and then editing that one?

[Aiste Marija Aidukaite-Urbanovic]

Hi Calvin, that makes sense. I tried something else already too, but that doesn't work either. It seems similar to what you suggest. Is there a reason why I can't use Assign the issue to and need to specifically use Edit issue fields? Because mine still doesn't work. 

[Aiste Marija Aidukaite-Urbanovic]

I have tried your recommendation, unfortunately doesn't work - any ideas what I'm doing incorrectly?

My trigger issue clearly has a parent issue, which in turn has an assignee. Still the error seems to be that it can't find an issue to copy from. I'm so lost at this point, this seems to be way harder than it should. That's the reason tbh why I tried branching.

[Calvin]

Hi @Aiste Marija Aidukaite-Urbanovic , thanks for the screenshots above, they are great!

In your last image I see your "linked issue" with the link type "is a child of" that then links to another "task". This is actually a different type of link to a parent-child that Atlassian uses. Which is why this won't work.

Essentially Atlassian is able to use "subtasks" to split apart issues instead, in your image you can see how they are created just under your name where it shows "Create Subtask". You will also see this is connected completely different to the "linked issue" way that you have. This would allow you to use the "Assign from Parent".

This might be more the direction you want to go, but just a heads up, subtasks are not able to be visible in the portal as you can't set a request type.

If however you want to continue using just "tasks" then it is a bit more complicated, and I feel there are some good solutions here: https://community.atlassian.com/t5/Automation-questions/How-to-copy-assignee-from-linked-issue-to-trigger-issue/qaq-p/1869878

I would however take a look at the business rules on this before going ahead. As you may find it easier to create these secondary tasks that you are linking as "a child of" type via automation, which would allow you to create the task and add the assignee in one go from the parent, instead of trying to reach out to the linked item to get field details and then bring it back.

[Aiste Marija Aidukaite-Urbanovic]

Hi Calvin, thank you so much. To be honest, this is all not super clear to me because I just started using Jira and I need to build a lot of automation. It feels quite counterintuitive to have a child/parent relationship for linked issues and then have a different type of child/parent relationship for subtasks... I certainly appreciated you explaining to me in detail, this is amazing help! :)

To provide a bit of context, I'm trying to recreate an ATS (Application Tracking System used in recruiting) in Jira SM. So the idea is like this:

1. The hiring manager (internal user) accesses the Portal and submits a recruitment request by filling out a form with a specific Request type ("Recruitment Request"). A task issue is created.
2. The candidate (external user) accesses the same Portal and applies by filling out a form with another specific Request type ("Apply for a Job"). A task issue is created. (I understand there is a way to restrict access/view to specific Request types, so I could set it up that internal users see both and external users only see Request type "Apply for a Job".)
3. The candidate will come to the Portal via a link from our Career website, so every job ad URL will carry the corresponding "Recruitment Request" type issue key, and in the "Apply for a Job" type form there is a hidden custom field that gets automatically prepopulated with that key.
4. I've built automation so that upon creation, "Apply for a Job" type task issue triggers a Lookup issues action to match the issue's custom field value to the keys of project issues, and positive match results in a "Link issue to trigger issue" action.
   This is the step I'm trying to automate at the moment - to automatically assign the trigger issue to the assignee of the "Recruitment Request" type issue, it's now linked to.
5. Next, I have some automation that triggers when recruiters change candidate application issues (X, ...) statuses. These result in emails sent to candidates.
   After there is an Apply for a Job issue with the status changed to Hired, I'll need to automate it so that the linked Recruitment Request type issue closes automatically, and all linked "Apply for a Job" type issues close automatically triggering emails to candidates.
6. And finally, regarding the "Apply for a Job" type issue that got its status changed to Hired. I also need to build automation that would at that point create an object in Assets. That object would need to inherit the summary and the values from the form fields of the "Apply for a Job" type issue, as well as be linked to the same "Recruitment Request" type issue.

Sorry for such a long comment, still I would really appreciate some opinions from an experienced Jira user/admin. Does this seem doable to you?
Also, you mentioned subtasks can't be created via Portal. So I need to stick with tasks or is there anything else I could try? Maybe an automation that converts a task to a subtask as it's linked to other tasks and becomes its child? Or is that way too convoluted?

[Aiste Marija Aidukaite-Urbanovic]

Any thoughts would be much appreciated. Ty

[Calvin]

Hi @Aiste Marija Aidukaite-Urbanovic ,

Thanks for the above, I think its doable within Automations, its just going to be a bit finicky for some parts of it. But I understand your need for both of them to be "tasks" now. 

Have you tried the smart query in the link, by using assignee value as: {{issue.issuelinks.first.inwardIssue.assignee}}

Its probably the simplest solution though keep in mind this would take the first inwardlinkedissue, incase you have a task that has multiple links or you need an outward link: {{issue.issuelinks.first.outwardIssue.assignee}}

By the way, not your question but these do sound more like "Service Requests" as opposed to tasks. Though I don't think that will make any difference functionally.

[Aiste Marija Aidukaite-Urbanovic]

Hi @Calvin thanks so much, I've tried using the smart value {{issue.issuelinks.first.inwardIssue.assignee}} approach, exactly as you show it in the screenshot, unfortunately, even though the audit log says it ran successfully, the trigger issue still is unassigned.

Now I'm going to try your other recommendation: https://community.atlassian.com/t5/Automation-questions/How-to-copy-assignee-from-linked-issue-to-trigger-issue/qaq-p/1869878, which looked really promising although I think I already got stuck lol. 

[Calvin]

Hi @Aiste Marija Aidukaite-Urbanovic ,

I had a go now, and instead of using "issueKey = {{lookupIssues}}" I used "issue = {{lookupIssues}}" and that looks to work on my system.

[Aiste Marija Aidukaite-Urbanovic]

Hi @Calvin , I can't believe it! It worked! Thank you so so much!

[Aiste Marija Aidukaite-Urbanovic]

Hi @Calvin!

Promise this is the last question on this thread. :))

My first rule, that links issues automatically, doesn't trigger the second rule that you helped me build, if I start the second rule with Issues linked trigger rather than Manually triggered from issue.

So I thought I will merge them both into one automation rule. It appears to be working quite well (I added Log action to see better), but the last step (And: Assign issue to: Copy from issue found via JQL) is erroring. I copied it exactly from the rule that we built together and which works perfectly when manually triggered. I'm not sure why this doesn't work now, do you have any ideas?

Issues:

ATSV3-1 - parent issue

ATSV3-13 - trigger issue (newly created)

[Calvin]

Hi @Aiste Marija Aidukaite-Urbanovic ,

It looks like you've been busy :)

Short answer, try using the "Re-fetch issue data" value before the branch but after your automation makes the link, it looks like this:

Long answer - the components that are run inside the automation takes the details based on what it looks like "before the automation". So when your automation starts there is no link, even if you add the link after in the automation, everything after it doesn't know that because it only knows what it looks like at the start before the automation has run.

Running re-fetch will pull the updated data and hopefully then it should see there is a link there and assign off it.

Just a heads up, automation rules don't trigger other automation rules unless you switch them on to do so under "Rule Details"

Cheers!

[Aiste Marija Aidukaite-Urbanovic]

@Calvin I switched it on and now it works as two separate rules :) thank you so so much!

[Bill Sheboy]

Hi @Aiste Marija Aidukaite-Urbanovic -- Welcome to the Atlassian Community!

To copy the field from the parent, use that option in the edit: "Copy from parent".  That will use the built-in parent / child relationship for issues.  For example, between and Epic and Story.

However what you show is "issue linking" and not the built-in parent / child relationship.  When you want to identify the issue by linking, that would need to use the key directly to find the assignee.

Kind regards,
Bill

[Aiste Marija Aidukaite-Urbanovic]

Hi Bill, thanks