ScriptRunner for Jira Cloud - Post Functions

[Kym Charlesworth]

I have some groovy code cobbled together that can look at an existing Jira Issue and extract the value of a custom field. Seems to work OK (code segment below):

...
// Fetch the issue object from the key
def issue = get("/rest/api/3/issue/${issueKey}")
.header('Content-Type', 'application/json')
.asObject(Map)
.body

// Get all the fields from the issue as a Map
def fields = issue.fields as Map

// Get the Custom field to get the option value from
def customField = get("/rest/api/3/field")
.asObject(List)
.body
.find {
(it as Map).name == 'Cost Centre'
} as Map

// Extract and store the option from the custom field
def costCentreValue = (fields[customField.id] as Map)?.value

...

I take that same code as a Workflow Post Function when creating a Jira Issue and it fails. I'm pretty sure that the fields variable (underlined above) is incomplete for some reason (based on logger.info) and so the costCentreValue ends up being NUL.

The overall idea is to inspect the Cost Centre value and assign the Issue to the appropriate assigneeId.

Can anyone point me in the right direction or explain why, as a Workflow Post Function, the code fails?

[Kate Kabir · Accepted solution]

Hi @Kym Charlesworth 

As for this, you need to log out the issue variable in your Post-Function to see how to access the fields. In a Post-Function, to specify an issue you will need to call it using issue.key as the issue binding is the script. So, you do not access the issue correctly, it will show as Null. 

Hope this helps.

Kind Regards

Kate

[Kym Charlesworth]

Thanks Kate.

I guess I had read it enough times about placing Post-Functions as the last step in a Workflow Transition (in this case 4). As soon as I did that per below then it worked.

1. Creates the issue originally.

2. Re-index an issue to keep indexes in sync with the database.

3. Fire a Issue Created event that can be processed by the listeners.

4. ScriptRunner workflow function: Run a script as ScriptRunner Add-On User: JiraSetAssigneeFromCostCentre

I do have a couple of follow up questions though !

a) How does one get the issue.key of the issue just created (that is really the first thing required in my REST API Step-Function)?

b) I really want to set the Approver rather than Assignee but from my reading, there is no REST call provided to update the Approvers field?

[Kate Kabir]

Hi @Kym Charlesworth 

For the newly created issue, you can just call issue.key as that will be the key to the issue that is just created.

To set the approver field you will need to call the Edit issue API and to set the approver field. You can use the Get Issue Fields example script on the Script Console page to see how data is stored below this field and what structure you need to use to set the field.

Hope this will help.

Kind Regards

Kate

[Kym Charlesworth]

Thanks but I am none the wiser.

I am using ScriptRunner for Jira Cloud.

The Issue has been created by filling out the Form in the Jira portal. That is, ScriptRunner code is not involved in creating the issue.

I have a Post-Function in the Workflow 'Create Jira' transition in order to set the assigneeID.

Before I even start, I need the issue key of the issue that Jira has just created.

issue.key is not going to work as the first line in the Post-Function because the variable [issue] is undeclared.

[Kym Charlesworth]

I think I am getting closer. Even though the ScriptRunner for Jira Cloud Post-Function complains that the variable [issue] is undeclared, it appears as though issue.key is available when the Post-Function runs. 

[Kym Charlesworth]

Still no luck. My Post-Function is below

def myIssueKey = issue.key

def myFields = issue.fields as Map

def myCustomField = get("/rest/api/3/field")
.asObject(List)
.body
.find {
(it as Map).name == 'Cost Centre'
} as Map

def myCostCentre = (myFields[myCustomField.id] as Map)?.value

myIssueKey logs out OK, myFields logs out (but gets truncated don't know why), myCustomField logs out OK and myCostCentre logs out as NUL whereas it should be G151

[Kym Charlesworth]

Well the truncation is explained in that logger.info with ScriptRunner is limited to about 2000 characters on a single line for performance reasons.

It is looking like issue.fields.(myCustomField.id) is NUL but I have no idea why. Once the Issue is created, then issue.fields.(myCustomField.id) from the Script Console returns the Cost Centre OK.

ScriptRunner advise to log out variables in the Script Console, but for the Create issue Transition with Post Functions, this is not the same thing. Unfortunately for me, my custom fields are outside the 2000 character limit so I have no way of troubleshooting by using logger.info to inspect as the Issue gets created.

I would suggest to ScriptRunner, that being able to turn on > 2000 characters for logger.info at the expense of performance is sometimes necessary to troubleshoot.

[Kristian Walker _Adaptavist_]

Hi Kym,

Thank you for your response.

Can you please try logging out just the individual fields which you require which you can do by adding a logline similar to logger.info(issue.fields.customfield_12345.toString()) where you replace customfield_12345 with the ID of the custom field you want to log out the value for.

This will then log out just the individual field specified on each log line.

Also, as you mention you are running your post function on the create transition then can you please check and confirm is the post function ordered below the post function named Re-index an issue to keep indexes in sync with the database in the list of post functions as if it is not below this one then the issue may not be created when the post function is run and this would cause the fields to be null.

Regards,

Kristian

[Kym Charlesworth]

Thanks for responding Kristian. Confirming that:

1. logger.info(issue.fields.customfield_10055.toString()) is null.
2. The order is below 'Re-index an issue to keep indexes in sync with the database'

After much testing, it is to do with ProForma Forms. The ProForma Forms fields are linked to the corresponding Request Type fields. It is my understanding that any change to a linked field will result in the change being reflected at both ends of the link. Certainly with ScriptRunner Workflow Post Function on the Create Transition, the Request Type fields have NULL values. At some point when the Issue appears on the Project, the fields have been updated to reflect what has been entered into the ProfForma Form when submitting. I'll have to ask ProForma Forms what is going on?

All ProForma Forms is used for is to add a regex to a couple of fields to validate input.

[Kristian Walker _Adaptavist_]

Hi Kym,

Thank you for confirming this, if the field values provided by ProForms are null then you will need to ask the vendor of Pro-Forms why this is the case as I can confirm ScriptRunner just returns the issues as Atlassian provide them when the issue is created.

Regards,

Kristian

[Peter Preston]

Hi Kym 👋

Peter from ProForma here. I was going to jump in here and respond with some advice, but it looks like you've had a chat with our support team. 

If you run into any more order-of-events type issues, please give us a holler and we'll happily work through it with you.

All the best,

Peter