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; } } }

Populate summary field with static text + values from custom field

Stian Bentsen Sveen

Hi,

My knowledge of scripting is very limited. I've been doing mostly configurations and automations in our JIRA based on pre-built functions or JQL.

I am looking to populate the summary field for a certain request type with some static text + values from two custom fields.

Its a form for "Create New Employee". I dont want the users input on the summary, I want it standardized. Today i've just hidden the summary and preset the value to "Create New Employee".

Since we are growing quite a bit, it can now be problematic to have a bunch of requests with the summary "Create New Employee without knowing which one is for which user.

Therefore I would like to also populate the summary with the custom field "Name" and custom field "Surname" as well as the static text so the summary after creation will be "Create New Employee - name + surname".

I've searched around, but most of the answers just states that you can use Scriptrunner / Behaviours for that, but no mention on how to do it.

I tried to understand it, but it just doesnt makes sense to me.

Can anyone help me with a groovy script for this so I can create a behaviour for this. It would also be incredibly helpful with some "help comments" on each step so that I can try to understand and learn why you're doing this or that, so maybe I can learn how to do this myself in the future.

Thanks!

Accepted answers

Mark Markov

Hello @Stian Bentsen Sveen

Are you using service desk?

As i understand the user must fill customfields name, surname and this info must be added to summary field, Am I correct?

Gezim Shehu [Communardo]

Hi,

Though I disagree with the "categorization" by summary, the actual automatic summary is a good approach.

You can surely do it in a lot of ways, but most propably in a post function during create transition. You need to add a custom script post function into the desired workflow (custom script post function - part of Script Runner)

Now here's the tricky part:

If you have your field configuration configured that Summary is required., which I assume you have as that's the default basically, you would need to add the Post Function at order 1, above the Create Issue post function.
There's also the option that your field config does not care about the summary and you can put the post function last (i'm only mentioning this since most cases you would put the post function at the last order)

Now if you got to this part, the script would look something like this

(I will try to write in details, not shortening, so you can follow the logic)

import com.atlassian.jira.component.ComponentAccessor

def customFieldManager = ComponentAccessor.getCustomFieldManager()



def myCustomField1 = customFieldManager.getCustomFieldObjectByName('Name of custom field 1')

def myCustomField2 = customFieldManager.getCustomFieldObjectByName('Name of custom field 2')

//if you have fields with same name, which btw bad practice, you can also use getCustomFieldOBjectById



//get values, you could also do it in 1 line

def value1 = issue.getCustomFieldValue(myCustomField1).toString()



//or

String value2 = issue.getCustomFieldValue(myCustomField2)




//set summary

def concatValue = "New Employee:" + value1 + value2

issue.setSummary(concatValue)





//done

All comments

Mark Markov

Hello @Stian Bentsen Sveen

Are you using service desk?

As i understand the user must fill customfields name, surname and this info must be added to summary field, Am I correct?

Gezim Shehu [Communardo]

Hi,

Though I disagree with the "categorization" by summary, the actual automatic summary is a good approach.

Now here's the tricky part:

If you have your field configuration configured that Summary is required., which I assume you have as that's the default basically, you would need to add the Post Function at order 1, above the Create Issue post function.
There's also the option that your field config does not care about the summary and you can put the post function last (i'm only mentioning this since most cases you would put the post function at the last order)

Now if you got to this part, the script would look something like this

(I will try to write in details, not shortening, so you can follow the logic)

import com.atlassian.jira.component.ComponentAccessor

def customFieldManager = ComponentAccessor.getCustomFieldManager()



def myCustomField1 = customFieldManager.getCustomFieldObjectByName('Name of custom field 1')

def myCustomField2 = customFieldManager.getCustomFieldObjectByName('Name of custom field 2')

//if you have fields with same name, which btw bad practice, you can also use getCustomFieldOBjectById



//get values, you could also do it in 1 line

def value1 = issue.getCustomFieldValue(myCustomField1).toString()



//or

String value2 = issue.getCustomFieldValue(myCustomField2)




//set summary

def concatValue = "New Employee:" + value1 + value2

issue.setSummary(concatValue)





//done

Stian Bentsen Sveen

Hi Mark,

Yes that's correct, they fill in those fields in the form (required fields) and if possible I'd like that information to be populated in the summary along with the static text when the issue is created.

Edit: and yes we use service desk

Stian Bentsen Sveen

Hi Gezim,

Thank you so much!

I'll look at this first thing tomorrow morning.

It's not as much categorization as it is an easy way of differentiating between multiple "New employee" tickets. They could just edit the request and include the name in the summary, but it would be even better to automate it.

If I can learn this that also mean I can probably do tons of other things with similar scripting, which is just what I'm after.

Mark Markov

Behaviours work on front-end side. It means that when users fill fields, summary field on screen will change dynamically. And this is means that users can change the summary after it fills automatically. If you need to change summary without users notice that, will be prefer to use @Gezim Shehu method with some corrections.
Behaviours preferable to use for set defaults for fields, like in this example

https://scriptrunner.adaptavist.com/5.4.12/jira/recipes/behaviours/setting-default-fields.html

(also recommend you to check this article about how to create behavior from the start https://scriptrunner.adaptavist.com/5.4.12/jira/behaviours-overview.html)

And to set field defaults in service desk, you need to create behaviour with mapping to service desk like this

Снимок экрана 2018-07-18 в 0.36.37.png

Then click on fields and Create Initialiser with code like this

getFieldById("summary").setFormValue("New Employee")

This is will fill summary field with "New Employee" value and your user will not need to fill this field.

After this you can use @Gezim Shehu [Communardo] postfunction to add usernames to summary field.

Stian Bentsen Sveen

Thanks @Mark Markov,

What we've done for each service request type is to hide the summary field with the value preset to the request type so the users dont have to fill in anything there, just the custom fields / description added to each form. This is because from experience, some users start writing the hole request in the summary field, incorrect info there etc (this is for internal IT support in our company).

The only issue type they can choose summary for is incidents as there only one form for that since IT does all the categorizations since users usually dont know what the cause of the incident is.

Would it be better to change this and create behaviors for this instead that populates the summary field for each request type?

For the requests where we will try to use scripting to add additional values to the summary it doesnt make sense to set a preset value on the request form if we have scripting that will replace it anyway.

Gezim Shehu [Communardo]

@Mark Markovalso has a good point. Behaviors would be my choice also, since in your case you have already defined a default value for the field.

Though issue is that you would monitor 2 custom field for changes.

Also it would require 2 updates, that's why I suggest you remove even the default one and add a post function at the top of the order to populate it. This way it would show up within the create event, just as that was the original user's input.

Events/Updates are always worth saving/grouping.

Stian Bentsen Sveen

@Gezim Shehu [Communardo] Thanks, I got it working with your script and with @Mark Markov input using behavior for default values as well.

Without using behavior to set a default value I got an error on creating because summary wasnt populated, even though I added the post function at the top of the order list (as you mentioned in the "tricky part").

I understand a bit more know and I guess using this in other contexts is just finding out which libraries I need to import and which commands / fields to use (easily explained ).

Now I just need to figure out the "if" clause to make this only apply for request type "Create New Employee" so it doesnt set this summary for all request types using that workflow, hehe.

Thanks for the help, both of you!

Tuarn McInerney

I wanted to update the summary field with the fields "first name" + "last name"

this is the script I ran in automation

"New User Access request for - {{issue.First Name}} {{issue.Last name}}"

New User Access request.jpg

Works a treat:)

Tuarn

Francisco Cardona

How can you include the start date in this example?

serge calderara

Simply in same way. Identify the field name on your issue and call it like issue.myfield.

Note :

In case of custom field your will have to provide the field ID name instead of field string

Welcome!

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

Quick Links

Find more posts tagged with

jira

developer