Comparing Two Custom Fields

[Kurt Huhner]

I have a custom jira type called Objective that has two custom fields:

1. Target Value - represents the target metric of the Objective (e.g., 100, 1, 5, etc). Any numeric value above 1.
2. Current Value - represents the current metric of the objective, Any numeric value from 0 to less than or equal to Target Value.

I'm new to the jira admin side of the house and have been investigating ways to enforce that Current Value is less than the Target Value. I've tried automation setups, smart fields, etc. and without using ScriptRunner (Groovy).  I haven't had luck getting this complete.  What suggestions do you have to address this?

[Bill Sheboy]

Hi @Kurt Huhner -- Welcome to the Atlassian Community!

There is no way to compare two fields using built-in JQL searches, although marketplace apps which extend the features of JQL may help.

And, with built-in features, the values of one custom field cannot be limited based upon the values in another field during add / edit of a work item.

If you have tried doing this type of comparison with an automation rule, perhaps if you provide more context the community can offer better suggestions.  For that, please post:

• an image of your complete rule in a single image file for continuity
• images of any rule steps where you are trying to compare the fields
• an image of the audit log details showing the rule execution
• explain what is not working as expected, and why you believe that to be the case

Kind regards,
Bill

[Kurt Huhner]

Bill,

Thanks for the intro and suggetions!

I was able to do this check in Automation for a NEW Ticket creation.  I couldn't get it done on Amendments.

I think it's doable in ScriptRunner (via Groovy) but I want to exhaust all other options first as I want to avoid coding.

[Bill Sheboy]

For existing work items, you could try a rule triggered on a change to either custom field...or a Scheduled trigger rule with JQL testing that both fields are not empty.  Then the rule conditions could check if the values meet / do not meet your criteria.

The Scheduled trigger approach could help identify items already existing without any data changes...although it will be limited to checking at most 100 items due to service limits.

[Kurt Huhner]

Bill,

I have got what I believed was the right syntax for your suggested approach, but the rule doesn't stop "invalid" values.  Can you review this and see if I'm missing something silly?

I tested and entered 5 for Current Value and 2 for Target Value which should have caused a rejection, but the jira was created.

Rule Trigger:

Condition:

Flow:

[Bill Sheboy]

Hi @Kurt Huhner 

First thing: for the rule you show, that will always try to transition the work item back to the same status it is currently in (i.e., a looping transition).  Is that what you wanted?

Next, what are the types of those fields: number, select-option, etc.?

Next, I personally recommend never using the new-ish feature to add conditions directly to triggers.

• There is too much risk of the known racetrack timing problems with some triggers causing unpredictable results
• Instead, try using separate conditions after the trigger
• And, for cases with a Work Item Created trigger, add a Re-fetch Work Item Data action after the trigger, but before the conditions

Finally, after any changes and re-testing, please post images of the updated complete rule and the audit log details showing a rule execution.