You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Join now to unlock these features and more
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?
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.
@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
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:
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.
@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.
Some things I would try/ask:
@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.
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.
@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.
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.
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.