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!
-Roberto
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
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) {
return
}
// 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!
-Roberto
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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()) {
desc.setFormValue(defaultValue)
}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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 5.6.7.1-jira8 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 5.6.7.1 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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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: https://scriptrunner.adaptavist.com/5.6.7/jira/behaviours-overview.html
Specifically the snippet:
if (!underlyingIssue?.description) {
desc.setFormValue(defaultValue)
}
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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();
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for the response @Aleksandr Zuevich It worked like a charm!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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,
michael
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Have you been able to find a clean solution to prevent the message from popping up?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
No, sadly not :(
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @Dennis Schamne
I have seen that you have consulted in different posts this same question.
Did you find the solution?
Regards,
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.