Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

ScriptRunner/Behaviours how to get information of an issue when you know the issue name

Hello Community,


I am having a bit of trouble with Behaviours.

I would like to know if there is a way to grab the contents of an Issue if you know the name of an Issue.

In my Behaviour script I get the name of an Issue (provided by a custom field). From there I would like to use the name of the Issue to find that Issue in Jira and discover its resolution status, from there I would like to have a conditional statement that if a certain Issue is resolved then I do something, else I do nothing.

I appreciate any help!



My Script currently looks as follows:

def formField = getFieldById(getFieldChanged()) //Grab the field my behaviour is attached to

def issueName = formField.getValue() // Grab the value in the field a.k.a the name of an issue in Jira


3 answers

2 accepted

7 votes
Answer accepted

Hey @Roberto Luces

What Aleksandr said is not wrong, but there is an easier way. You can use the variable underlyingIssue, so if you are in any screen, except the Create Issue (which I guess this is not the case) then youcan use someth like 

log.debug "Issue is $underlyingIssue"

// the issue does no exist (probably you are in a create issue screen)
if (! underlyingIssue) {

// those are saved values in the issue and NOT necessary the current values in the form, use
def reporter = underlyingIssue.reporter?.displayName
def description = underlyingIssue.description

// in order to get the current value in the form
def descriptionValueInForm = getFieldById("description").value

So the underlyingIssue wll be an Issue

regards, Thanos

Hey @Thanos Batagiannis [Adaptavist] 

Thank you for the response, just like Alek's this worked wonderfully as well. 

I apprecaite you taking the time to help me out with this!


Hi @Thanos Batagiannis [Adaptavist] ,


What I'm noticing is that it works fine when viewing the create screen for the first time, but when I change the issueType I get the following error message:



My script is:


def desc = getFieldById("description")

def defaultValue = """
h2. Overview

As a user, I would like to...

h2. Outcome

The outcome of this story should be...

h2. Value

The reason why we're doing this is...

h2. Acceptance Criteria

* Step 1

if (! underlyingIssue?.description && !desc.getValue()) {

Hi @Rafael Franco and welcome to community :P

This is intentional.

I don't remember exactly in which version we introduced it, but the reasoning behind it, is that if you have written something in a text area, and then make a change that will wipe out the text in that area, then show that kind of flag.

But we are open to suggestions.

Regards, Thanos 

Thanks @Thanos Batagiannis [Adaptavist] for the warm welcome ;)


Yeah I get it, but isn't there a way to say if the field is not empty don't show the flag?

Like IC Admin likes this

Hello @Thanos Batagiannis [Adaptavist] , 

The preservation of the values when a different Issue Type is selected is understandable.
But what's also weird is that when you select back the Issue Type that had default values for description, the description gets overwritten.
What workaround can be applied?

@Thanos Batagiannis [Adaptavist]  I think this is actually a bug in Script Runner / Behaviours.

We have just upgraded from Jira 7.12 and script runner 5.4.49 and our existing Behaviours initialiser script now doesn't work how it used to and appears to be very similar to @Rafael Franco 's issue as well as what @Michelle Pogado commented above.

We are now running Jira 8.5 and script runner and script is below:

import com.atlassian.jira.component.ComponentAccessor
import com.onresolve.scriptrunner.runner.util.UserMessageUtil

def description = getFieldById("description");

UserMessageUtil.success('Description is: [' + description.getValue() + '] value is null? ' + (description.getValue() == null))

if (description && !description.getValue()) {
description.setFormValue("""||Task||Done (/) or (x)||
| | |

h4. +Text in need of modification:+

h4. +Explain why:+\n\n\nh4. +Suggested Text:+

h4. +Relevant Output Examples and show commands:+
{noformat}Surround output with { noformat} tags to get fixed-width font.{noformat}

h4. +Relevant Config Example:+""" )

 Note that the if statement is:

if (description && !description.getValue())

So only when the Description field is on a screen, and it has no value, should default text be applied.

Instead what we find with Jira 8.5 + script runner when you click on the description to edit it in-line, it opens up the standard Edit window and script-runner replaces the existing description field content with the value in the script, and has the pop-up box on the right with the original field content.

But in Jira 7.12 + script runner 5.4.49, it just let you inline edit normally, because the check for "!description.getValue()" would prevent it from replacing existing content. This is the same check that Rafael has in his script above and the same comment made by Michelle as well.

I tried upgrading script runner on our old jira server instance, so I upgraded from 5.4.49 all the way through to 5.6.7 running on Jira 7.12 and the script worked correctly in all cases.

So it seems like the problem has been introduced either by Jira in 8.x, or in the script runner stream that supports Jira 8.x, or some combination of both.

The UserMessageUtil line is an extra debug statement I added to check what was going wrong in the script. It appears that even when there is text present in the Description field, description.getValue() is returning null. See screenshot.
jira-behaviours bug.png
Are there any workarounds that you can think of that might work for this? In the mean time we've had to disable this script because it's hugely disruptive for users trying to edit the description of an issue having it replaced by the default template.

I got in touch with Adaptavist support about my above comment. In short, there IS a change in behaviour between 8.5.1 and 7.12 but not the one I thought (see below for more info).

The proper way to update system fields with default values is on their documentation page here:
Specifically the snippet:

if (!underlyingIssue?.description) { 

This means the field is only set if there isn't already content in it, rather than the (description && !description.getValue()) clause that I was trying to use to prevent this.


Turns out the script never really worked the way I wanted it to work in 7.12 anyway; if you clicked Edit the content in the description field would be replaced by the template, it's only if you used the in-line edit functionality that the initialiser script wouldn't fire at all and therefore no content would be replaced. The change in 8.5.1 is now that when you try to do an in-line edit of the field, it will force the Edit window to open, and then the initialiser script runs and replaces the content.

1 vote
Answer accepted

Hi Roberto,

you can obtain IssueManager and then use it methods like getIssueObject, getIssueByCurrentKey etc.

import com.atlassian.jira.component.ComponentAccessor;

IssueManager issueManager = ComponentAccessor.getIssueManager();

Thank you for the response @Aleksandr Zuevich It worked like a charm!

I don't remember exactly in which version we introduced it, but the reasoning behind it, is that if you have written something in a text area, and then make a change that will wipe out the text in that area, then show that kind of flag.

But we are open to suggestions.

It's annoying if i am in the creation-process.

Please make it possible that one can get rid of the message.

I am in a creation-process. Depends on the issueType i set the description.
If one change the issueType then i would set a new description.
If one has changed the description manually i can evaluate it by myself and can desicde if i will overwrite it or not.

But if the description is the same as i set programmatically then i would like to change it without the message.

Kind regards,

Have you been able to find a clean solution to prevent the message from popping up?

Like # people like this

Hello @Dennis Schamne

I have seen that you have consulted in different posts this same question. 

Did you find the solution?



@3digits - Desarrollo - No, I did not find a solution. I'll try to contact Adaptavist, maybe they can make that warning optional in the newer version of ScriptRunner or something like that.

Like 3digits - Desarrollo likes this

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events