Scriptrunner for getting the current key on runtime in production environment

[Kalyan Kumar Das]

The new JIRA has been installed and i am facing the issue in script-runner. I m searching for 4 days.

The two point is provided below which i need to fix:

1. I am unable to restrict for update the value of an issue at the time of issue update event. I had created a script on script listener.

2. Instead of hard coded value for key, i want to use dynamic code on script-runner. Means if the ticket is sub-task issue and project will be the same then the below script will execute.

Here the script is provided below and the requirement is duedate value for Task IssueType should be greater than the Duedate value for n number of subtask IssueType :

import com.atlassian.jira.issue.MutableIssue
import com.atlassian.jira.issue.Issue
import groovy.transform.BaseScript
import com.onresolve.scriptrunner.runner.customisers.ContextBaseScript
import com.onresolve.scriptrunner.runner.util.UserMessageUtil
import com.opensymphony.workflow.InvalidInputException

//

@BaseScript ContextBaseScript script

Issue issue = getIssueOrDefault("TEST-258") // Hard coded issue-key defined

if(issue.parentObject.dueDate.compareTo(issue.getDueDate()) >= 0)
{
UserMessageUtil.success("Due Date Success"+issue.dueDate)
log.debug(issue.getDueDate())
}
else
{
UserMessageUtil.success('Please enter the Subtask duedate that is less than Parent-Task Due-Date ')
//throw new InvalidInputException("Input not valid")
}

The problem is that when the condition fails then the date will be update first and next the pop up alert is raised which i mentioned in the code but I am unable to restrict the due date update. Also recommend us for second point on run-time environment(on production).

[brbojorque]

Hi @Kalyan Kumar Das ,

So your requirement is to prevent the Subtask from being created/saved if the Due Date of the Sub-task is greater than the Due Date of parent task?

Then you should use Behaviour to validate it from being created/saved in the first place.

Issue Updated event in the listener assumes that the value is already saved as opposed to preventing it from being saved.

[Nic Brough -Adaptavist-]

You could also use a validator on the create (sub-task) transition.  This might be better than a Behaviour because it will work for REST and other automations, can't be bypassed by javascript tweaks, and it will take the person back to the "create issue" screen with all their data intact and a warning on the relevant field, with a lot less code!

[Kalyan Kumar Das]

@Nic Brough -Adaptavist-: I am not getting your point. Request you to elaborate the same.

Because i had already used the validator on the create(sub-task) transition. And it is working fine at the time of creating the issue but it is not working at the time of issue update event.

May be i missed something in the code?   

[Kalyan Kumar Das]

Request you to update on that. In case of any required from my end, please let me know.

[Nic Brough -Adaptavist-]

But the code you've given us

• Overrides the current issue object with another one
• Looks at the parent of the fixed issue (we don't know if it even has one)
• Compares the due date of the parent of the fixed issue with a date in 1970

So it's always going to pass validation

Could you give us the actual code?

And also bear in mind that a validator only executes on the transition it is on.  Editing an issue is not a transition.

[Kalyan Kumar Das]

But in workflow, there is no any transition defined. I had created a script listener in which i had defined in the project name and event(Issue Updated Event). 

For reference, the screenshot is already attached on that above.

[Nic Brough -Adaptavist-]

A listener has no validators itself, it runs when an event is detected.  It is up to you to put code in to detect if you want to do things selectively.

Listeners do not have any UI interaction.  They can't - they're not being run on the UI, they run in the background when events happen.

The code you've shown us is a validator, not a listener.

I think we need to take a step back.  Forget the code you have, and tell us what you're actually trying to achieve?  What do you want the user to experience?