Automation, JQL, and iterating with an index

[Thomas P]

Hello everyone !

I'm trying to use automation rules to prioritize tasks.
I tried following what was advised in a similar thread but to no avail. 
I currently have a JQL query that gives me the issues I need, and they should be in the correct order :

project = {{issue.project.key}} AND fixVersion = "{{issue.fixVersions.name}}" AND issueType in (Task) ORDER BY Importance ASC, Priorité DESC, OriginalEstimate DESC

The rule is (for now) triggered manually through a user action in an issue, which is what gives the correct project and fixVersion.
The issues have a "auto-prio" field, and all I want is to put their index when looping through that lookup in that field.

From what I read, I understand that's not something Jira likes to do.

I've tried using smartValues or a Variable, but I don't really know how to use them, and I don't understand how to put the correct value in the correct issue.

Any help with that would be greatly appreciated.

[Bill Sheboy · Accepted solution]

Hi @Thomas P -- Welcome to the Atlassian Community!

First thing: solutions for a scenario like this can be "brittle" because the ordering is dependent of fields which can easily / frequently change.  Thus an automation rule would need to reorder the issues frequently.  Please consider that before proceeding.  With that disclaimer out of the way...

For a question like this, context is important for the community to help.  Please post the following:

• what type of project is this (e.g., company-managed, team-managed, etc.), 
• an image of your complete automation rule in a single image for continuity,
• images of any relevant actions / conditions / branches,
• an image of the audit log details showing the rule execution, and
• explain what is not working as expected and why you believe that to be the case.

Until we see those...

The Lookup Issues action gathers the data for the issue using a JQL expression, but it does not allow editing them: the rule has the data but not the issue in scope for edit.  And, the {{index}} for the position within the data is only available while iterating the list.

A branch on JQL would support editing each issue, but because such branches run in parallel and asynchronously, the processing order is unknown.  Thus the "index" cannot be found.

If both of those features were used with dynamic list searching methods, the index could be found for setting a field value.

Before proceeding, I recommend reading the above linked sources and article before trying this method.  That will make it easier to see when there are problems and how to solve them.

For example, assuming you want a number from 1-N, where N is the lookup count:

• trigger: some trigger, such as manual
• action: lookup issues with JQL with an ORDER BY clause
• smart values condition: check if there were issues found before proceeding
  • first value: {{lookupIssues.size}}
  • condition: greater than
  • second value: 0
• action: create variable
  • name: varKeyWithIndexList
  • value: {{#lookupIssues}}{{key}}:{{#=}}{{index}} + 1{{/}}{{^last}},{{/}}{{/}}
• branch on JQL: using the same JQL as from the lookup
  • action: create variable
    • name: varRegularExpression
    • value: ^({{issue.key}}:.*)
  • get the index value with this expression
    • {{varKeyWithIndexList.split(",").match(varRegularExpression).substringAfter(":")}}

Please note well: the trigger issue cannot be included in the branch on JQL...even when it matches the JQL criteria.  This is a built-in rule feature to prevent a looping error.  When the trigger issue also needs to be updated, process that one separately, and outside of the branch, using the same two steps as inside the branch.

Kind regards,
Bill

[Thomas P]

Hi @Bill Sheboy and thank you for the answer.

The code you provided works perfectly.

I understand that, since it's not something Jira was made for, it may be dangerous to use it.
This is something I currently use as a test to check whether more advanced stuff with automatically ordering issues would be possible, but since the automation rule already takes 12 seconds to give their index to 6 issues, I don't think it would be great for a real project with higher numbers of issues to order.

As far as "not using the rule too often", I realized it with my earlier tests, and used a non-task issue to trigger the rule manuallly.
I would have loved to be able to have a button to trigger it on a Release directly, but I want the user to be able to trigger the issue-sorting rule manually (since it's "brittle" as you said, and I want to avoid triggering it too often).

Anyway, thank you for your help ! :)