Changing the status of a subtask

Martina February 17, 2024

Hey all, 

 

I am looking to make a rule that:

when a subtask #1 is marked as done, then change the status of the subtask #2 to to do.

The problem is that subtask #1 is the child of task #1, subtask #2 is the child of task #2 and these tasks (1 & 2) are linked. 

I have been trying to pursue this by using this code, but it isn't working. I wonder if you have any suggestions. Thank you so much in advance!!

P.S. Apparently what isn't working is the smart values condition :/ 

Screenshot 2024-02-17 at 21.15.43.png

2 answers

1 vote
Trudy Claspill
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 17, 2024

Hello @Martina 

What are the details in the Audit Log for the execution of this rule?

Where did you get the idea that this was a valid smart value?

{{triggerIssue.parent.LinkedIssues.key}}

How are tasks 1 and 2 linked? What type of link is used? Can task 1 have more than one other task linked to it using the same link relationship that is used for task 2?

This is a fairly complex indirect relationship that you are trying to follow. Have you considered instead creating a directly link between subtask 1 and subtask 2?

Do you have any third party apps that extend the capabilities of JQL, such as ScriptRunner Enhanced Search or JQL Search Extensions?

Martina February 17, 2024

Hello Trudy,

 

Thank you so much for getting back!

1. Screenshot 2024-02-17 at 22.16.17.png

2. I invented it, I know the bold part works: {{triggerIssue.parent.LinkedIssues.key}}, I also tried: {{triggerIssue.parent.issuelinks.key}} but it doesn't work either. 

3. Tasks 1 and 2 are associated using the normal link. Yes, task 1 can have more than one task similar to 2, linked to it. 

 

4. How would you suggest making a direct relationship between subtask 1 and 2?

 

I haven't tried ScriptRunner, do you think it's possible this way?

 

Thanks!

Trudy Claspill
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 17, 2024

1. Thank you.

 

2. You can't "invent" smart values. ;-) You can use only valid smart values. And what you have attempted to use is not valid. You can find more information about what are valid smart values for an issue type of object here:

https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/

 

3. Exactly which link type is used? Most Jira instances have multiple link relationships that might be used such as blocks/is-blocked-by, clones/is-cloned-by, etc. Can you provide a screen image of a sample Task #1 showing the Issue Links section and point out which of the linked issues would qualify as "Task #2"?

 

4. Depending on the type of Issue Links that have been created in your Jira instance you might use something that indicates a dependency such as depends-on/is-depended-on-by

subtask #1 is-depended-on-by subtask #2

subtask #2 depends-on subtask #1

If you have a direct link between the subtasks then it will be easier to construct the rule. Depending on being able to confirm the link between the parent issues makes the rule much more difficult. I don't know if it would be possible to construct the rule without the aid of an app that extends the JQL capabilities. I haven't had time to try to work through that scenario.

Martina February 17, 2024

@Trudy Claspill thanks!

How can I add a dependency between subtasks?

Task #1 is DPLY-324 while Task #2 is DPLY-346

Screenshot 2024-02-18 at 00.32.36.png

Thank you!

 

Martina February 18, 2024

hey @Trudy Claspill 

I wonder whether this could be solved using a variable or web request?

I am not sure about adding dependencies between these subtasks because I don't know how to do it, but maybe the other solution I said?

 

Thanks!

 

Martina

Trudy Claspill
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 18, 2024

Is the parent Task of subtask #1 always going to be linked to the parent Task of subtask #2 with the "Contained Deployment" relationship?

Screenshot 2024-02-18 at 12.21.10 PM.png

I said "add a depedency", but in more general terms I mean link the two subtasks together directly using a unique link type that you can rely on in this rule to tell you which destination subtask(s) (the subtask 2's) need to be changes when the source subtasks (the subtask 1's) have been updated.

You did not indicate with your post tags if you are an admin for your instance. It would be very helpful to us to know the types of links available on your instance. 

If you are an admin, you can get the information. Otherwise you'll need to ask an admin to provide the information. The page we need to see is

https://<yourBaseUrl>/secure/admin/ViewLinkTypes!default.jspa

 

If it is possible to link the subtask #1's directly to the subtask #2's that will need to be updated, that will make this rule much easier to construct.

If that is not a viable option, I'm not sure if it is possible to construct a rule that can find subtask #2's based on your criteria without the aid of a third party app that would extend JQL capabilities. At this time I don't have the time to try to figure a rule out based on that.

There are, of course, other community members who have done more complex work in Automation Rules than I, and may be able to offer a solution that doesn't involve third party apps.

 

Jack Brickey
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 19, 2024

I too agree with rethinking things a bit here. Linking the two associated subtasks would be important in solving this as Trudy mentions. In so doing you can simplify the rule to simply trigger on the subtask transitioning and then transition the linked subtask.

Like Hana Kučerová likes this
Martina February 20, 2024

Hey @Jack Brickey @Trudy Claspill

thank you for getting back to me!

I am still not sure how to link these subtasks, is it a parent / child relationship that you are suggesting? Also for context, subtask #1 would be related (linked) to more than one subtask from the other task. 

 

Thanks!

Trudy Claspill
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 20, 2024

You would use the generic issue linking functionality:

Screenshot 2024-02-20 at 1.24.21 PM.png

 

When you click that button you should see something like this:

Screenshot 2024-02-20 at 1.25.24 PM.png

In the pull down list you choose the type of relationship. In the field on the right you enter the issue key for the other subtask.

The options available in the pull down list are customizable by your Jira Administrators, so we don't know what options are available in your instance.

Jira Admins can define link types, and provide "inward" and "outward" descriptions for the link. The inward and outward links are used to describe the relationship between the issues. Here are the values on my system:

Screenshot 2024-02-20 at 1.29.09 PM.png

 

In automation rules you can make decisions and select related issues based on link type. You can use the name of the link type (i.e. "RelatedBug") or the inward/outward descriptions. So for instance you could say 

"for the current issue get me all issues related to it as 'is cloned by' "

...and then make changes to just the issues that are related to your source issue by that link.

I would advise you to use a link type that has different values for the Inward and Outward description. Trying to use "relates to" is challenging because the text doesn't help you figure out which issues is subtask 1 and which is subtask 2.

You may want to consider a link type that is not used for anything other than the relationship you want to use for this process to ensure this process can zero in on just the specific issues you want to impact. 

Like Jack Brickey likes this
0 votes
Rebekka Heilmann _viadee_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 19, 2024

Hi @Martina 

I would 100% second @Trudy Claspill in the suggestions to simplify the relation between the Subtasks. Even after reading the thread I am still not 100% sure of how you're issues are connected and what you are trying to achieve from a business point of view.

Back to your current setup and automation rule, it would be helpful to get details of all steps to really understand what's going on.

The "for" branch looks weird. What are you trying to do here? Will that JQL always only return one issue? Are you not simply trying to get to the Issues parent or are you trying to get the other Subtask?

LookupIssues and LinkedIssues are Lists. If you are certain they contain only one issue in your case, you can access the first element (which will be of Type "Issue") by get(0) or "First" so accessing the first Element's key in LinkedIssues of the Triggerissue should look like:

Triggerissue.LinkedIssues.get(0).key or Triggerissue.LinkedIssues.First.key

 

Check out Jira smart values - lists | Cloud automation Cloud | Atlassian Support

Martina February 20, 2024

Hey @Rebekka Heilmann _viadee_ ,

 

I have different tasks that have different flows, and different subtasks. The problem is that 2 subtasks (one from each task) are related. I wonder how would you add a dependency between these 2 subtasks?

A little bit more of context:

As I mentioned these 2 tasks have subtasks with different statuses: blocked, to do, in progress and done. Blocked means that the subtask is not ready to be done. Once a subtask (let's call it #1) from Task #1 is marked as done, this enables subtask (let's call it #2) from task #2 to be done, therefore, its status should be modified to 'to do'. 

subtask #1 is the one in the first if function, and subtask #2 is the one in the for function. There will be more than 1 subtask #2 associated to that subtask #1 since there are more than one tasks #2 associated to only one task #1. I was trying to filter all of the subtasks (they contain that summary) that are associated to the subtask #1 that changed status. I mentioned 'blocked' too because this rule will change them from 'blocked' to 'to do'. Hopefully this isn't confusing. 

 

Where are lists used? in the for command?

 

Thanks!

Rebekka Heilmann _viadee_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 21, 2024

@Martina 
Against all other advice (which still is, to link the Subtasks directly per "Blocks" Link Type - description provided by others) I managed to create a rule to achieve what you asked.

Assuming that what you said in the last comment is true 100% of the time:

1. Trigger and conditions need to be adjusted to your needs. TriggerIssue is the Subtask #1

2. Get the issues parent

3. Lookup the Linked Issue Task #2 -> they need to be linked by a specific LinkType. If you don't use the "is blocked by" you need to edit that part

4. Lookup the Subtasks of the first Issue (assuming this would always be Task #2)

5. Branch over all Subtasks (you need the "Related Issues" branch type, not the Advanced one)

6. transition the issues (or edit or do whatever)

Screenshot 2024-02-21 094009.pngScreenshot 2024-02-21 094141.png

 

Again: Recommendation would be to link the Subtasks directly. You can reuse parts of the first Lookup for reference on how to get linked issues

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
TAGS
AUG Leaders

Atlassian Community Events