How to validate/stop/quit/rollback issueevent?

[Laszlo Kremer]

I am writing a listener plugin, and I need to stop the issueUpdated event. The listener is meant to check a condition and if the condition is true, we should stop the event and rollback the changes.

If anyone could paste for example an issueUpdate validation, I would really appreciate.

[Nic Brough -Adaptavist- · Accepted solution]

That will not work.

A listener is there to listen to events and you've got three major structural problems with this idea

1. Events that happen to Issues are fired after successful completion of whatever process triggered them.
2. Listeners are independent of the processes that fire the events. A listener does not know what process caused the event to fire and it certainly can't talk to it, let alone influence it
3. There's no such thing as "roll back" in Jira. Once something has happened, it's happened, recorded, logged and committed.

If you need to prevent a transition on an issue, you need to prevent the user starting it with a condition, or add a validator to prevent them committing it if they've entered something wrong.

The best you'll be able to do with a listener is capture the update event, interrogate it for exactly what was changed and then physically undo every change listed in the update. That will still leave tracks in the database, probably really annoy your users who will be asking where all their changes went and is probably a pain in the neck to code

Could you explain exactly what you're trying to achieve here? Rather than the technical solution you've got above, tell us what the behaviour is now and what you'd like to end up with.

[Laszlo Kremer]

Thank You for the answer!

Thanks explaining how events and the listeners behave, this helps a lot.

My goal is to create a fixVersion name validation at issue update. An issue with a fixVersion which fits into the pattern is allowed to save.

The listener does perforce fix creation already, and this would only happen on successful validation.

[Nic Brough -Adaptavist-]

Ok, that's sensible. There's stuff you could do in javascript (which a sneaky user could bypass of course), and other partial tweaks, but the best solution I've got for you has been described by Jobin already

[Laszlo Kremer]

Ok, I marked this answer as the resolution, because it was the most informative for me, but thanks a lot Jobin and Renjith!

[Jobin Kuruvilla [Adaptavist]]

I would go with Nic on most of what he said. It is difficult to rollback all actions in a listener without knowing all the implications - like workflow post functions triggered for example.

If you want to validate onlt the fixVersion as you mentioned in the comment, a better method would be allow editing of fixVersion only in a workflow operation and don't put it in edit screens. By doing this, you can use workflow validators to do the validation!

[Laszlo Kremer]

Thank You Jobin,

this is a nice solution! Well rethink how we need this function.

[Renjith Pillai]

Or as Jobin says in his post, use some Java script to the validate the fixVersion while editing.

http://www.j-tricks.com/1/post/2011/12/one-fixversion-please.html