I have an if statement that has two conditions:
a field check and a related issue condition checking if a JQL condition is present .. the if is successful (which is what I would expect).
within that if, I have a branch - the branch branches on the exact same JQL condition from the if and fails with "No related issues could be found.". If i log the JQL issue and search on it, the issue is found.
thoughts on why this might happen? diane
Hello @Diane Fahr
Whenever you ask for help with an Automation rule, it will enable us to help you more effectively if you provide screen images that show the full automation rule, the details of each step, and the output from the rule execution audit log.
@Trudy ClaspillThank you Trudy, I have attached the flow that is failing (sometimes) - here is the flow -
1. a new initiative is created and during this creation a squad story and sub-tasks are created.
2. a custom field is set which in turn triggers this automation
a. the if condition is (add a new squad, and if the squad story exists, but a specific sub-task does not exist - then take this leg. (this always passes the first pass).
3. a new squad is added to the initiative and their story / sub-tasks are created.
4. since the custom field is already set this automation runs again.
5. the if statement passes (as expected) however the identical branch fails on the second pass with:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Diane Fahr
As the JQL for your conditions and the branch are dynamic (i.e., based on some variables and data) I recommend adding writes to the audit log to confirm they contain what you expected.
For example, before the Related Issues Condition you show, perhaps write this to the log:
JQL for Related Issues Condition: the JQL you use
Doing the same before each condition / branch using such JQL. When you next test your rule, you may review the audit log to help assess what you are observing.
Next, from the section of the rule you show, there are multiple JQL branches, each of which will run in parallel and asynchronously. There is no guarantee of when these will finish, up until the last rule step, and so the branches could collide with each other and other rule steps / conditions.
Kind regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill SheboyI have added logs and it writes what i expects and the branches are set up in such a way I do not car what order they run in .. the perplexing thing to me is
why pass in the if and fail on the branch, I am not changing the values that were passed in via the web hook .. I will post more data after I collect additional log information .
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This is the first pass -
SQUAD A
first branch renames existing issue
second branch creates a new issue
all is right as rain .. second pass log is coming next..
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This is the second pass and as you can see the JQL resolves using an advanced search - but not in the automation. I will run the third pass, but what it will show is
SQUADC if will pass
first branch will rename SQUADC's sub-task
second branch JQL statement will resolve to SQUADB's story and create the new sub-task in SQUADBs story, however SQUADC will not get the new sub-task until SQUADD is introduced.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for that additional information, and...
There appears to be duplication in your JQL where these expressions are included twice:
issuekey IN childIssuesOf("ABC-1234") AND issuetype = Story and summary ~ " Readiness"
I suggestion removing the second instances of those in the JQL to help diagnosing this.
Next, I wonder if there is a timing problem related to to the evaluation of the ScriptRunner parts of that JQL when used in a branch. This hypothesis could be tested by:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill SheboySo, you hit the problem right on the head .. my if statement has two conditions Condition A and Condition B .. the branch has one condition - Condition A - yes they are identical by design .. this is the flow
IF -
1. Find me all of the stories that have sub-task A, but not sub-task B ..
2 and it is an add, i fall through
Branch 1
1. rename sub-task A
Branch 2 -
1. Find me all of the stories that have sub-task A, but not sub-task B ..
2. Create a new sub-task, sub-task B - which is a compliment to sub-task A
The reason I need to branch is I only want to find the stories that have Sub-Task A and not Sub-Task B and since the only part of the summary that is identical from story to story are the final characters on the sub-task. specifically every sub-task looks something like this:
"Readiness" {{squad}} {{initative_key}} {{initiative_summary}} - <<IDENTICAL TEXT>>
I have considered a timing problem, but if that were the case then I would expect to fail on the if branch on the second iteration .. but since there is no real way to pause the automation being invoked, I did try inserting one / many re-fetch commands with no luck.
Ideas? thanks, diane
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for clarifying, and I was noting the duplicated JQL expressions in each of the condition and branch, not that it was used in both. That still seems to be a thing, based on what is shown in the audit log :^)
Scenarios like this are often problematic because the Summary field is being used to store multiple pieces of information, rather than using separate custom fields to hold that data (and perhaps only then using those fields to merge into a text expression to update the Summary). So one solution approach is to separate the fields to simplify queries.
Given the Summary for the Sub-tasks is in the format you describe, and one of them is being re-named during the rule, I expect timing challenges.
How about this approach:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill SheboyI have the list of sub-task using the lookup function, but honestly i do not know how to turn that list into JQL, also I am not using cloud Jira, but rather the on prem version.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, I noticed you appear to be using Jira Data Center, and that should not matter for using the lookup results this way.
Let's say you wanted to branch on JQL to all of the issues found for a lookup issues result. The JQL would be this:
key IN ( {{lookupIssues.key.join(", ")}} )
That will create a comma-separated list of the keys for the JQL to work.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill SheboyCloser!! the new issues were created (minus the first one on the list) .. having said that I am going to reset my test back to scratch and start over .. i will keep you updated.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill Sheboyfirst pass .. worked as expected .. was only one squad ..
second pass .. failed .. here you go .. (the automation is the same as what I shared earlier .. this is just a snippet)
my branch is .. key IN ( {{lookupIssues.key.join(", ")}} )
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Please post an image of all the audit log details for that run of the rule. Thanks!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill SheboyMy log doesnt have a lot of details, like why doesnt the branch work .. but here you go ..
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for the log information.
Are you capturing and then editing that audit log information before posting it, perhaps to obfuscate information?
Next, the trigger issue for that rule execution appears to be "ABC-32228". And, the issue the JQL branch is trying to access is the same one.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill Sheboy- yes, I changed the project key, yes it is a single project scope.
the trigger isssue for the rule is either a story or an initiative
I am trying to branch of the children of either the initiative to determine if the sub-task I am seeking exists of not (that is the if)
then the branch determines if the new sub-task is not there .. then create one ..
so yes I expect if the trigger issue is a story, then i would branch on that story and make the sub-task under that story .. the exact, unedited JQL is
issuekey in childIssuesOf("{{webhookData.initiative_key}}") and issuetype = Story and summary ~ "Development Readiness" and issueFunction in parentsOf("project = ZRM and type = Sub-Task and summary ~ 'Secure Lifecycle'") AND issuekey in childIssuesOf("{{webhookData.initiative_key}}") and issuetype = Story and summary ~ "Development Readiness" and issueFunction not in parentsOf("project = ZRM and type = Sub-Task and summary ~ Pre-GA")
which says .. look under the initiative (the key is passed in via the webhook call) .. if there is a secure lifecycle sub-task, but not a secure lifecycle subtask that says Pre-GA then go into the branch to create the Pre-GA sub-task.
This works, but never on the first call after the initial creation. the LookupIssues function does find the key .. but the next branch - that is branching on the LookupIssues value (which is there) fails that it cant find it ..
I am a bit stumped..
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Regarding you second-to-last paragraph:
This works, but never on the first call after the initial creation. the LookupIssues function does find the key .. but the next branch - that is branching on the LookupIssues value (which is there) fails that it cant find it ..
The log indicates the issue is found, and as I described earler: the JQL branch cannot access it when it is the trigger issue.
I have a suggestion: this rule is trying to do too much, and as a result the complexity may be preventing all of the cases to work. Please consider splitting this into multiple rules to perform each "case", and test them one by one.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill Sheboygiven this is the first if statement of the rule I would not have thought the rule was too complex ... but I wanted to clarify, so where i am trying to do the branch to create the new issues, call another rule using a webhook and pass the issue I want to branch on?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That is difficult to assess as we have not seen an image of the complete rule, in one single image. If you provide that, it may help understand how to proceed.
And, although one rule can trigger another rule using a webhook, I would only recommend that for edge case scenarios. Instead, I was suggesting creating a rule which does not use the if / else block, and instead only performs the actions for one path of the current rule. That will help isolate what is / is not working as expected.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill SheboyI cannot create a rule that runs directly from a trigger - my rule is called by a webhook.
So taking a step back, this is the flow.
- We have a custom field that contains all the squad names that are working on that initiative.
- We require at least one squad name before the initiative moves to discovery.
- Upon moving to discovery we create a structure for each squad that contains a story and several sub-tasks.
- One of the squads indicates this initiative will be provided to clients early by setting another custom field, called CLIENT.
- this kicks automation to run - which runs a rule that creates an epic to track the work and runs a second rule that renames and creates the new sub-task (this comes from the rule i have been sharing).
- everything works fine on this first pass, regardless of how many squads there are.
- a new squad (SA) is added which triggers a series of rules that creates that squads story - sub-task structure, and because CLIENT is set, the rule I have shared with you is executed. This is the first squad add, and eventhough you can get the story key a number of ways, branching on the story key fails (as the logs from before show).
- if I add yet another squad (SB), and the process runs again, the branch on the story passes because it finds SA and not SB.
- this trend continues for as many squads as I add.
Other things to note:
- the branch on the sub-task (to do the rename) always works and this is under that new story.
- if I add two squads at the same time, both squads will be processed .. but if i follow adding two, by adding one (the final one will fail on the branch).
It is not possible to call the rule based on a trigger from an issue.
I have been able to get the story key in the calling rule and pass it via webhook. I have taken the branch out of the if statement and make it the first thing that is processed, and even though i am passing in the key to branch on - it works as I describe above.
If it is a timing issue, something hasnt synced? or something? even though the lookupIssues finds the key but the branch cannot find the key, is there something that can be done, a delay, a something?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for the additional details, Diane!
On your last question:
If it is a timing issue, something hasnt synced? or something? even though the lookupIssues finds the key but the branch cannot find the key, is there something that can be done, a delay, a something?
I hypothesize this is the built-in behavior where JQL branches cannot include the trigger issue. The only workaround I can think of for that is using if / else and two branch types:
Thinking about the entire scenario, although this one may be easier with Jira Cloud's version of rules (as it has the advanced branch over smart values), the scenario would still have potential race-track error / timing limitations. One cause is the values of the multiple-select field for the Squads could change while rules are still running. One way to solve that may be with process changes...
Starting with the check to only allow transitioning an Initiative to "Discovery" when there is at least one Squad selected, could that be done with a workflow validator? Doing this would avoid the need to check the Initiative status in any follow-on rules.
Where is the custom field Client: in the Initiative?
When is this field set by one of the Squads?
When do the Story and Sub-tasks for each Squad need to exist: what is the event / trigger for that need? If only needed during Discovery, the transition of the Initiative could be the trigger for a rule to create them...and that rule could call a recursive, Incoming Webhook triggered rule to progressively add the issues for each Squad. The assumptions are:
With that approach, changes to Squads could be edge cases, and a manually triggered (or field value changed trigger ) rule could be used to address that only when an Initiative is already in Discovery.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill SheboyI am going to start backwards ..
The initiative starts in To Do and at the time of transition to Discovery the field that holds the squad names (one or more) must have at least one. When the initiative is in Discovery is when the story / sub-tasks need to exist.
The trigger to transition from To Do to Discovery is a manual trigger, after transition the trigger is a new squad being added to the list of squads.
The Client field is set when the team determines they will provide early code - in other words, can be anytime.
We are hoping Jira Cloud becomes available to us sometime in the near future, we have very little (no) control of the environment and that can make things difficult.
I want to play a bit more with this .. im trying to decide if i know at any given point what my trigger issue is .. i dont think i have the problem when the trigger is the initiative, but i have the problem when the trigger is the story ..
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
As you already have a rule started, try that last bit to see if it helps with the Initiative vs Story as the trigger.
If not, I could envision 4 rules:
Of course, if the number of Squads is fixed and less than 20, a ginormous if / else block could be used to add their issues, without the risks of recursion. That block would be replicated in rules #1 and #4.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill SheboyIs there a handy dandy way to get a list of issue minus the trigger issue? I have played with lookupIssues replace triggerIssue with "", but either that is not possible or i do not have the correct syntax .. so i was curious if there was another way to get the list - trigger?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes...you may add this to the JQL for the Lookup Issues action to exclude the trigger issue:
AND key!={{triggerIssue.key}}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill SheboyI think I realized although I heard what you were saying, i wasnt really getting it .. but the gist is this
You cannot branch on a trigger issue
You can perform operations based on the trigger issue by using an IF statement
Since your rule may either trigger from an initiative or story you have to handle both cases because you always want the subtask under the story ..
so .. if the trigger issue is a story .. create a subtask and save that value in a variable
if it is an initiative .. branch on the story and create the subtask and save the variable ., do a few other things then use a webhook to send data to another project area
however, your first IF statement may not have completed, and your second IF statement triggers the webhook but you dont have the data from the first IF
and all. of this because you cant branch on the trigger issue and you cant control the flow of the automation
that is a big sigh from me :-)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill SheboyI had some success with initial testing and it was all because of not being able to branch on the trigger issue ..
having said that, I have another question for you and I am assuming it is a similar problem to not being able to branch on the trigger issue, this time is is trying to link. I have a webhook that calls another project and send the issue number .. I log the issue number, the issue size (for no reason other than i wanted to convince myself it wasnt 0) .. but when i try to link the rule believes the issue does not exist .. here is the log.. is it the same problem as above, but with links this time?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Just to clarify, a rule cannot use a branch on JQL to the trigger issue (because the rule automagically adds a clause to the JQL to remove it). Other branch types will work with the trigger issue.
For the linking symptom, in that log it appears the issues are in different projects. What is the scope of the rule: single-project, multiple-projects, or global?
A single-project rule cannot access issues in other projects for linking, reading, etc. (It can only create or clone into other projects.)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill Sheboythank you for clarifying .. i did test with link on current issue, but since the trigger issue can be an initiative or story i can control where the new sub-task is linked .. regardless I think i have it navigated .. having said that - the linking is weird, sometimes it works and sometimes it does not .. we are mulitproject and all our development projects are in a category. we use webhooks to communicate with other projects and send the data that way.. I will admit we have a pretty complicated automation solution ..
regardless, we do take advantage of liking other projects to our initiatives .. here is an example .. sometimes it does work and sometimes it doesnt .. ill play with it .. i really appreciate all your help, i have been stuck for a couple months :-(
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Perhaps compare the specific issues (and audit logs) for the cases that worked versus those that did not to help pin down the root cause.
And as an FYI when posting the images, please try to post them at a higher resolution and remove the extra blank space at the bottom. That will make it easier for the community to see the details. Thanks!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.