I'm trying to create an automation for the following scenario, but I'm stuck and need help. Step 1: tickets are assigned a numeric "master priority" (custom field)* Ticket A = master priority 1 * Ticket B = master priority 2 * Ticket C = master priority 3 Step 2 - Ticket D is assigned master priority 1, and the other tickets automatically bump down as follows: * Ticket D = master priority 1 * Ticket A = master priority 1 -> 2 * Ticket B = master priority 2 -> 3 * Ticket C = master priority 3 -> 4 I tried the automation above, but it only bumps down Ticket A and not the others. The result looks like this: * Ticket D = master priority 1 * Ticket A = master priority 2 * Ticket B = master priority 2 * Ticket C = master priority 3 I also tried using a "lookup issues" action, but it didn't work at all. Help!

Hi @Gerald Oliver First thing: what problem are you trying to solve by doing this? That is, "why" do this? The built-in capabilities for ordering / re-ordering issues with the Rank field work well, although they do not provide a 1-to-N numbering. Back to your question... IMHO, a rule to handle a scenario like this is theoretically possible, and may not be practical. Let's assume your goal is: * Each issue has a unique, numeric value for the Master Priority, custom field * When the Master Priority of an issue is changed to another number, and there are issues with a greater-than-or-equal-to value for Master Priority, the Master Priority of each of those issues is incremented by 1 * When a new issue is created, it is handled as if an issue with a Master Priority value was changed * ??? When an issue with a Master Priority number value is cleared, do ??? * ??? When an issue with a Master Priority is deleted, do ??? * ??? When an issue with a Master Priority is moved to a new project, do ??? * ??? When an issue with a Master Priority is moved to a different issue type, do ??? * ??? When an issue with a Master Priority number value is negative, do ??? Your first idea of using a branch looks correct, and perhaps add to the JQL a condition to only grab issues where their Master Priority is >= the trigger issue value. That will eliminate the need for the rule condition comparing to the trigger issue's Master Priority. Some challenges with a rule like this are: * Timing, and race-track errors: Branches on more than one thing are executed in parallel and asynchronously. The only reason this rule might work is because the values are only incremented and it is assumed they already correct. However... * If there is a mistake and the rule triggers again in rapid succession, the behavior will be unpredictable * If the rule does not run, due to an automation engine or infrastructure error for Atlassian, the behavior will be unpredictable * Branches can only execute on up to 100 things, and so if you are trying to use this solution approach for more issues it will not work Kind regards, Bill

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How do I auto-increment the value of a numeric custom field for all issues in a project?

Gerald Oliver

I'm trying to create an automation for the following scenario, but I'm stuck and need help.

Step 1: tickets are assigned a numeric "master priority" (custom field)

Ticket A = master priority 1
Ticket B = master priority 2
Ticket C = master priority 3

Step 2 - Ticket D is assigned master priority 1, and the other tickets automatically bump down as follows:

Ticket D = master priority 1
Ticket A = master priority 1 -> 2
Ticket B = master priority 2 -> 3
Ticket C = master priority 3 -> 4

Screenshot 2023-11-02 at 2.51.38 PM.png

I tried the automation above, but it only bumps down Ticket A and not the others. The result looks like this:

Ticket D = master priority 1
Ticket A = master priority 2
Ticket B = master priority 2
Ticket C = master priority 3

I also tried using a "lookup issues" action, but it didn't work at all.

Screenshot 2023-11-02 at 3.00.11 PM.png

Help!

Accepted answers

Bill Sheboy

Hi @Gerald Oliver

First thing: what problem are you trying to solve by doing this? That is, "why" do this?

The built-in capabilities for ordering / re-ordering issues with the Rank field work well, although they do not provide a 1-to-N numbering.

Back to your question...

IMHO, a rule to handle a scenario like this is theoretically possible, and may not be practical.

Let's assume your goal is:

Each issue has a unique, numeric value for the Master Priority, custom field
When the Master Priority of an issue is changed to another number, and there are issues with a greater-than-or-equal-to value for Master Priority, the Master Priority of each of those issues is incremented by 1
When a new issue is created, it is handled as if an issue with a Master Priority value was changed
??? When an issue with a Master Priority number value is cleared, do ???
??? When an issue with a Master Priority is deleted, do ???
??? When an issue with a Master Priority is moved to a new project, do ???
??? When an issue with a Master Priority is moved to a different issue type, do ???
??? When an issue with a Master Priority number value is negative, do ???

Your first idea of using a branch looks correct, and perhaps add to the JQL a condition to only grab issues where their Master Priority is >= the trigger issue value. That will eliminate the need for the rule condition comparing to the trigger issue's Master Priority.

Some challenges with a rule like this are:

Timing, and race-track errors: Branches on more than one thing are executed in parallel and asynchronously. The only reason this rule might work is because the values are only incremented and it is assumed they already correct. However...
If there is a mistake and the rule triggers again in rapid succession, the behavior will be unpredictable
If the rule does not run, due to an automation engine or infrastructure error for Atlassian, the behavior will be unpredictable
Branches can only execute on up to 100 things, and so if you are trying to use this solution approach for more issues it will not work

Kind regards,
Bill

All comments

Bill Sheboy

Hi @Gerald Oliver

First thing: what problem are you trying to solve by doing this? That is, "why" do this?

The built-in capabilities for ordering / re-ordering issues with the Rank field work well, although they do not provide a 1-to-N numbering.

Back to your question...

IMHO, a rule to handle a scenario like this is theoretically possible, and may not be practical.

Let's assume your goal is:

Each issue has a unique, numeric value for the Master Priority, custom field
When the Master Priority of an issue is changed to another number, and there are issues with a greater-than-or-equal-to value for Master Priority, the Master Priority of each of those issues is incremented by 1
When a new issue is created, it is handled as if an issue with a Master Priority value was changed
??? When an issue with a Master Priority number value is cleared, do ???
??? When an issue with a Master Priority is deleted, do ???
??? When an issue with a Master Priority is moved to a new project, do ???
??? When an issue with a Master Priority is moved to a different issue type, do ???
??? When an issue with a Master Priority number value is negative, do ???

Some challenges with a rule like this are:

Timing, and race-track errors: Branches on more than one thing are executed in parallel and asynchronously. The only reason this rule might work is because the values are only incremented and it is assumed they already correct. However...
If there is a mistake and the rule triggers again in rapid succession, the behavior will be unpredictable
If the rule does not run, due to an automation engine or infrastructure error for Atlassian, the behavior will be unpredictable
Branches can only execute on up to 100 things, and so if you are trying to use this solution approach for more issues it will not work

Kind regards,
Bill

Gerald Oliver

Thanks Bill, this is helpful. My team tried using Jira's built-in ranking, but it wasn't intuitive when moving across columns. Also, we'd like the ranking to be visible. The ranking will be contained on a single board in a single project and will be applied to 25-50 tickets at a time (not every ticket in the project). If I can get this automation to work, I'll use a similar one to cover when a master priority is deleted.

I'll try adjusting the jql as you described and see if it works. How do I include the trigger issue's master priority value in the jql? Is it something like this?

project = "Feature Quest" and issuetype = "New Feature" and {{issue.Master Priority}} >= {{triggerIssue.Master Priority}}

Thanks again!

Bill Sheboy

Adding on to the JQL you already have, please try:

AND "Master Priority" >= {{triggerIssue.Master Priority}}

But before you do that, please check a couple of things...

Confirm that field name in JQL, perhaps with a test query outside of the rule in View All Issues.

Next, smart values are name, spacing, and case-sensitive. And, the smart values sometimes do not match the displayed field name on the Jira issue views. Please confirm your smart value (or the custom field id) using this how-to article:

https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

Gerald Oliver

This seemed to do the trick. Thanks so much!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

automation