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

Fire Issue Event manually without changing status

Guilherme Peres

Hello!

I'm trying to find a way to manually fire a specific event from JIRA issues without having to update it, since it has to remain on the same status, and it needs to be possible from any status (of a very long workflow).

This question has a good method of doing so from an escalation service, but in my case, I need to be able to do it manually from the issue screen itself. I was thinking of using a little plugin with web-items, but I don't know if that could actually execute code, instead of just using it as context or condition. Maybe a link, but I didn't find anything about firing events from the REST API.

Is there a way to do this? Is it a wrong approach in any way?

Accepted answers

Nic Brough -Adaptavist-

Peter beat me to the best answer, but if you do want to do this without add-ons, you can. Add a "looped transition" to the workflow whereever you need to trigger the event, one that goes back to the same status.

This will do what you want, but has drawbacks - it's in the workflow, you have to edit your workflows to do it, and it writes to the issue history (mixed bag on that one - you'll get an audit log of who triggered notifications and when, at the expense of an issue history that could contain a lot of "issue didn't really change" lines)

All comments

Peter DeWitt

@Guilherme Peres, look at Scriptrunner. You can add a web item and tie it to a backend script that will fire you event.

Nic Brough -Adaptavist-

Guilherme Peres

@Peter DeWitt, thank you for your suggestion. We have Script Runner, but still at the free version (3.1.4), and can't afford the paid version with our current Jira license. From what I've seen, web items are only supported from version 4.3 (or 4.1.3.11) onwards, so that's a limitation.

Guilherme Peres

@Nic Brough -Adaptavist-, that's actually what we've been doing for some time in some statuses, but our workflow currently contains 93 different steps, and still tends to grow. I'm trying to take it out of the workflow for that reason, because our team is demanding it on different steps, but it still remains as an alternative.

If there was a way to make it a global transition, but coming back to the same status as before, that would probably be the best case for us.

Peter DeWitt

@Guilherme Peres, if you can't afford the Scriptrunner add-on Nic's suggestion on the looped transition will be the way to go.

Guilherme Peres

We ended up just adding transitions along the workflow like that. Will keep doing it by demand, on required statuses.

Nic Brough -Adaptavist-

Mmm, the obvious instinct is that you've probably got 80 too many steps in the workflow. Also, probably more to the point, the desire for arbitrary "fire event when nothing has actually happened" suggests you've set up Jira to do something that might be more sensible to do in another tool.

A good example of this was an old client who, while they had a small workflow, triggered hundreds of events from a few status within them. Turned out they really needed a build tool like Bamboo, as their events were "please build, given info in Jira". Properly integrated, that moves into Bamboo.