how to change a custom "Scripted Field" value within a transition, using a post function?

[Roni z]

Hi all,

I have a Scripted Field named "Reopen Counter" that increases (counts) every time the ticket changes through transaction "reopened".

If this transition was made by mistake,  there is an option to press a transition called "Undo Reopen"

How is it possible to decrease the Scripted Field named "Reopen Counter" when pressing the transition "Undo reopen"?

Thanks!

[T0pH0ur]

You can do both of these on the transition in the workflow. You may then just want the initial script to create the field with a default value.

Open each Transition and add a Post function Custom Script runner script

I believe this should do it for you, but may need to check for syntax and be sure to find the actual value for your field

import com.atlassian.jira.component.ComponentAccessor;
import com.atlassian.jira.issue.Issue;
import com.atlassian.jira.issue.CustomFieldManager;
import com.atlassian.jira.issue.fields.CustomField;

//define values
long OpenCounterFieldID = 00000L;   //<-change this value to be your scripted field value
def IncrementVal = 1;

try{

     //need to define the field manager
     def customFieldManager = ComponentAccessor.getCustomFieldManager();
 
     //use the manager to get the field object for OpenCounterField using the field value defined above
     CustomField OpenCounterField = customFieldManager.getCustomFieldObject(OpenCounterFieldID);

     //only try to use the field if it exists
     if (OpenCounterField){
          def counterVal = issue.getCustomFieldValue(OpenCounterField);
          counterVal += IncrementVal;  // <--use -= for the duplicate script on the Undo Re-Open
          issue.setCustomFieldValue(OpenCounterField, counterVal);
     }
} catch (Exception e){
     println("Calculation Script Failed")
} 

[Roni z]

Hi @T0pH0ur, thanks for the quick response! the issue is that I have the first already configured as a Scripted Field (as an Add-on),

this is the script for adding +1:

import com.atlassian.jira.ComponentManager
def componentManager = ComponentManager.getInstance()
def changeHistoryManager = componentManager.getChangeHistoryManager()
Double counter=0
changeHistoryManager.getChangeItemsForField(issue, "status").each{
if (it.toString=="Reopened")
{
counter=counter+1
}
}

return counter

and it works.

I can't change this now because I will loose all my history...

Do you think that if I use what you suggested for the second part (reducing) it will still work although the field is not "long" but a "Scripted Field"?

[T0pH0ur]

That should work fine as the script in the field is returning to itself and not needing to be set.

The long is used to hold the field ID value. if you check the field in custom fields, it will exist there as a scripted field. just click the cog, hover the configure option and look at the URL at the bottom

use this value in the script and only put it in the transition for Undo and it should be fine

[Roni z]

Hi @T0pH0ur- thanks, but Iv'e tried it and it does not work :(

I changed in the script you sent the field ID and set  counterVal -= IncrementVal and added it as a custom script in the "Undo Reopen" transition and it does not work..

Any other suggestions maybe?

Thanks!

[Nic Brough -Adaptavist-]

Which app are you using to generate the "scripted field", or, probably more importantly, how does it work?

I ask because when you say "scripted field", most Apps that provide scripted fields don't actually store the data directly - the value is calculated, usually from other fields and data on the issue.  With that type of "scripted field", you don't try to change the value, the script behind it recalculates, so you'd need to edit the script to look further into the history and taking account of re-opens.

If you really mean a standard (numeric?) field that you don't let users edit, but instead, increment with a post-function or automation when the "reopen" button is pressed, then you should be able to reuse the same method - just decrementing on "undo reopen"

We can probably help you more if you can tell us what the field is (which will tell us how you're doing it!)

[Roni z]

Thanks for the quick answer- you are right!

I am using the script runner add-on. 

this is the code:

import com.atlassian.jira.ComponentManager
def componentManager = ComponentManager.getInstance()
def changeHistoryManager = componentManager.getChangeHistoryManager()
Double counter=0
changeHistoryManager.getChangeItemsForField(issue, "status").each{
if (it.toString=="Reopened")
{
counter=counter+1
}
}

return counter

the issue is that when counting+1 - this is the only time that the status changes to "reopened", while wanting to "Undo reopen" the status changes to "Fixed" and it can change to this status from other transactions as well...

Can I buy pass this somehow?

thanks!

[David Fischer]

To count reopens, you can check it.fromString to check from which status you're coming, in addition to checking to which status you're going.

[Nic Brough -Adaptavist-]

Thanks @David Fischer - that's what I was going to say too!

[Roni z]

you are both right- but it is already configured and in use in a different manner for a long time now, and if I change it I will loose all the history I already have..

The issue is that there are 2 different transaction moving from status "Reopened" to status "Fixed"  and only in one of the 2 ways I need the counter to (-1):

1. moving from status "Reopened" to status "Fixed"  via transaction "Undo reopened" 

2. moving from status "Reopened" to status "Fixed"  via transaction "resolve" 

and only in #1 I need the counter to (-1).

Is there another way to decrease a counter?

Thanks

[Nic Brough -Adaptavist-]

There are plenty of ways to change the counter, but I think you need to modify it as David said to make it work the way you need.

[Roni z]

Will this delete my history?

How would you set this up?

tried reading about it.fromString and didn't really grasp how it is done

[Nic Brough -Adaptavist-]

No, it won't affect the history - the field is independent of the script - the script just updates the field when it is run.

Personally, I'd do what David said - add an "if" into the script so that it increments when going from status A to status B, and decrements when it goes the other way.

[Roni z]

Thanks @Nic Brough -Adaptavist-

The thing is that there are 2 different transactions that start in the same status and resolve in the same status and the counter should decrements only in 1 out of the 2 transactions:

when moving from

1. status "Reopened" to status "Fixed" via transaction called "Undo Reopen" the counter should decrements

2. status "Reopened" to status "Fixed" via transaction called "Resolve Issue" the counter should not be changed.

Any idea on how to solve this?

it will be very much helpful!

the current code I am using is:

import com.atlassian.jira.ComponentManager
def componentManager = ComponentManager.getInstance()
def changeHistoryManager = componentManager.getChangeHistoryManager()
Double counter=0
changeHistoryManager.getChangeItemsForField(issue, "status").each{
if (it.toString=="Reopened")
{
counter=counter+1
}
}

return counter

and I am struggling to figure out the other part I need

Thank you- this is very appreciated! 

[David Fischer]

In that case, you won't be able to differentiate the two transtitions from the change history. You might want to try the JMCF app instead, that provides a Transition count custom Field type that supports this use case. 

[Roni z]

thanks @David Fischer- ill check it out, Do you believe that if i add this Transition count custom Field to my workflow (on top of the current  Scripted Field  "Reopen Counter" that I already have) they will work together- I don't see how this is possible- how will they "speak" with on another? will the Transition count custom Field be able to change the counter that is defined in the Reopen CounterScripted Field? 

[David Fischer]

No, this would be meant as a replacement for your existing Reopen Counter field. And since calculated fields reconstruct data on the fly, they work well on past data (such as past transitions).