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

How to pass custom arguments to issue event?

Alex Trebek

Hello!

Is it possible to add custom arguments in post-function (or somewhere else) that can be accessed by issue event listener in ScriptRunner?

Like transientVars but outside of the workflow.

For example, we need a listener on IssueCreated event in which some logic should be based on values of custom field which are getting changed during creation (in post-function), so there is no information left when IssueCreated eventually fired.

I realize that in this example "the logic" should be added as a post-function. But for some reasons it's more convenient to use a listener instead. Also we have other instances where custom parameters in Event data would have been of a great value.

Accepted answers

Nic Brough -Adaptavist-

There's no way to do this directly - the issue event can only contain the data that the transition contained at the end, no matter how it got changed.

Generally, I strongly recommend that you do not change issue values that the humans put into the transition screen in post-functions, because you will get "hey, that's not what I put it, why is it broken?" responses from your people. It's a really bad practice.

But, I can think of a work-around - dual fields.

Create a second field, with a different name. I would make it non-searchable, and only put it on the transition screen.

Your post function can then recalculate and post your actual field from the value the user entered, not adjusting the field they actually entered.

Then when your listener gets the updated event, it will contain both the value entered by your person and the new value for the real field.

All comments

Juan Carlos Vera

You can Use the "Automation".

An the Trigger of this can be a Transition to One Status to other (you can put the status ytransition that you want).

Then you can play with the Custom Fields

Alex Trebek

Hi, Juan!

Thank you for the response.

Unfortunately, it's not enough. It's easy to use groovy as well for just listening for changes in statuses.

The problem is that not every change event is needed, but specific ones during which something happens that cannot be determined on Event level.

For example, user can set checkbox in transition screen, but a post-function with specific rule in specific conditions adjusts the checkbox value. In event listener of GenericEvent which is fired for transition the information of checkbox value set by user is lost as the value was modified by post-function.

If it was possible to add custom param to event then it would have been to use it for conditions of the event listener.

Nic Brough -Adaptavist-

There's no way to do this directly - the issue event can only contain the data that the transition contained at the end, no matter how it got changed.

But, I can think of a work-around - dual fields.

Create a second field, with a different name. I would make it non-searchable, and only put it on the transition screen.

Your post function can then recalculate and post your actual field from the value the user entered, not adjusting the field they actually entered.

Then when your listener gets the updated event, it will contain both the value entered by your person and the new value for the real field.

Nic Brough -Adaptavist-

Oops, sorry, too fast.

I would also code your listener to set the "ghost" field to the new value, so that on the next transition, it has the real value displayed.

And, maybe think about using a scripted field instead - user enters something, something else is calculated based on existing information and the results of the post-function.

Alex Trebek

Thanks Nic!

Fields manipulation during transition is only one example when additional info in Event object would have been helpful. So I decided to check if it is really not feasible route.

"Ghost" field is a good workaround for cases with a field-related logic. So thank you for the hint!

I'm also thinking about using Issue properties via IssuePropertyService. By this potentially it would be possible to set property in post-function and then check it in the event listener.

Nic Brough -Adaptavist-

That would work too, I went with custom fields because I'm more familiar with them.

Welcome!

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

Quick Links

Find more posts tagged with

server

scriptrunner

jira-software

jira-software-server