Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How to validate/stop/quit/rollback issueevent?

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.

2 answers

1 accepted

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

0 votes
Answer accepted

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.

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.

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

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

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!

Thank You Jobin,

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

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


Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you