Field edit automation is bypassing issues in the lookup Issues list.

[Danno]

Per @Trudy Claspill I am starting a new request for help with this automation issue. The original question was from this conversation: How can I produce a specific kind of aging report without add-ins. 

My automation works well except it does not process all of the issues found in the lookup. There are less than 100 issues so I don't think that is the problem.

Here is what I have so far:

The search in the lookup Issues validates to a filter I am using to find every open "Discrepancy Report" which returns 84 issues. Below are issues that do not get updated.  The issues that have the blank space in the far right column do not get processed for some reason which has me baffled. It's not an editing permission for the project since it has processed some of them. Any suggestions?

I can post the rest of the automation rule although it seems to be working correctly. The audit log indicates that the rule sees every issue, but if you look at the log you will see that the issues above that haven't been updated in the right-hand column are not in the log results.

[Bill Sheboy · Accepted solution]

Hi @Danno 

Adding on to the questions from Stefan...

Does the scheduled trigger have JQL or is the rule only processing issues from the Lookup Issues result?

If it is only processing issues from the Lookup Issues result, my assumption is the rule is using a branch to perform the update.  When you post images of your complete rule, please also post images of the branch.  That may help to explain the symptom.

The list of issues you show span multiple projects.  What is the scope of your rule: single project, multiple project, or global?  A single project rule would not be able to access the issues in different projects.

Kind regards,
Bill

[Danno]

@Bill Sheboy The search function is the same for both the trigger and the lookup. They both validate with 84 issues which is the same issue count that I get using the search as a filter to validate my results. That is what the partial results show above. My results indicate that the branching is working as far as the calculation is concerned. I started working on this with a single project to get it to work and then changed it to a global automation to accommodate anywhere that issue type gets used. My results in th

[Bill Sheboy]

Thanks for that information, as it may explain the unexpected results you are observing...

As you have shown, the JQL is the same for the trigger and the Lookup Issues action.  What is the purpose of doing that lookup?

What is the purpose / value of the timeStatus created variable?

You mention a branch, but there is no branch in your rule.  Instead what this rule will do is:

• once per day, and for each issue found with your JQL (84 issues)
  • lookup the exact same issues (84 issues) the trigger is looping over
  • some logic to update the issues

A definite side-effect is as each issue changes, the results returned by the next call to Lookup Issues will be different.  And as the loops are likely processed in parallel (not one-by-one), the results are unpredictable.

[Danno]

@Bill Sheboy I originally tried to just use the trigger search to get the issues to process but since the original automation wasn't working at first I thought I had to double down on it. I will try it again w/o the lookup issues action.

[Stefan Salzl]

Hi @Danno 

Some things I would try/ask:

• Could you add a log action after the lookup to output the issues/keys of the lookup action?
• Could please show us your whole rule as well as the details of its components as well as the rule details?
• regarding the rule details: Who is the actor of the rule? Is there any other user than your user running the rule? I‘m asking because I also think of some configuration with issue security levels. If there is another actor than ours who did the jql it could be that the list could not be edited.

Best
Stefan

[Danno]

@Stefan Salzl I added the log action to the rule on your suggestion so that I could more easily identify the issues that were not getting processed although the right-hand sidebar indicated I was capturing all of the issues. I ran the rule and the results log listed all of them. I do not know why but I seemed to have changed something that has caused it to run correctly. I can't show you the log with all of the results yet. The rule should run automatically this morning and I will check it again as I expect some of the issues to move to a new category. I will post more results after that happens.

[Stefan Salzl]

what does your variable look like?

Did you expect to run through your lookup issues? As the rule seems right now it processes each issue from the jql. I dunno what the lookup issues action is for as it‘s not use later eg. for the edit actions.

As I said I have no information what the timeStatus is but from what I can see from your screenshots I would guess that the if/else-if blocks sort out the issues and therefore not edited.

Hard to analyze as we still can‘t see all the necessary configuration.

Best
Stefan

[Danno]

@Stefan Salzl my bad. I forgot to explain that. So the idea here is that the variable is used to update a custom field on each issue in the results. It calculates the number of days since the issue was created and then updates a custom Time in Status field which is then used for reporting. I will also consider updating the rule to just use the search results from the trigger to verify I don't still need the lookup issues action.

[Stefan Salzl]

From the issue list screenshot in your original post:

As we can´t see the column header: are the dates we see in the 3rd column the create dates?

The list shows many dates in the year 2022. Are there further else-if components in the rule that handles older issues?

Looking forward seeing the autdit log information.

Best
Stefan

[Stefan Salzl]

Hi @Danno 

just wanted to follow up on this. Are there any further information?

Best
Stefan

[Danno]

G'day @Stefan Salzl from your earlier post I thought I had explained that the dates in the far right column were the ones of interest when they initially were blank due to not being processed by the automation. It was particularly confusing given that at least two of the ones were being passed over. The rule would process an issue in a project, then skip two issues and process a fourth one.

I didn't insert all of the If/Else statements (there are only four) since they were all working on the issues that were being captured by the search criteria.

Now the rule seems to be working but as I went to check the audit log, I found the rule was turned off and I don't know why yet. Other than that, it is working correctly now so I don't want to upset the apple cart.

I still need to try it in the sandbox with just the trigger search and w/o the second lookup action.