Here's the scenario: After issue has been created, it needs to be approved by someone in a certain group. However, when a person who is in this group creates the issue, this step is pointless and we'd like to make the issue automatically transition to approved status.
I use IssueService to transition issues from a plugin and normally it works. Not from onIssueEvent (Issue Created) though. I get a failed transition with no errors:
Invalid Transition: {}. Reasons: [] Transition result: false
There are no errors, it just fails. My guess is it's because the issue hasn't been completed yet. I tried to run the same code AFTER the event and transition went smoothly. Mind you: the event fire is the last operation in the Post Functions.
I then tried another approach to do transitions (stole the idea from here). This code worked, however I got an exception from JIRA this time: "Error creating issue: Can't transition workflow instance #28809. Current state is 3, requested state is 1". I'm guessing whatever JIRA does to the issue after the event failed now because I forced the new status.
Finally, I reverted back to my old version and just put it in a separate thread that delays the transition. This works but the user has to refresh the page to see the new status since it's delayed a little.
My question is - what would be the correct way to do this? Maybe something I have overlooked? I am using Jira 5.1 if that matters.
Community moderators have prevented the ability to post new answers.
I can't see where you are doing this. You're talking about events, which implies a listener, but you also mention post-functions.
The main starting point here is that you can't really do this in a post-function. Subverting the end-point of a transition is an utter nightmare. I like it for the personal reason that I've been paid to fix the mess it's made of people's Jira systems when someone has tried it. I have yet to see or hear of anyone successfully changing the end-point during a transition.
So, that leave us with a listener which picks up an event and pushes the issue through another transition to the desired state. That should work ok, except that because it executes after the transition that fires the event, you simply can't fix the "user has to refresh for new status". The user has been returned to the issue view after the first transition, and that screen is unaware of the action of the listener.
But, I can't see which one, or both, you have tried here?
Sorry for lack of clarity - I did it in a listener. I only mentioned post functions because that's where the event is fired from ('Issue Created' event which is processed by the listener).
So then there is no way to do this transition so that users don't have to specifically refresh the issue? Otherwise it's bound to cause some confusion for users.
Thanks for the reply.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ah, good, I'm afraid, yes, you are stuck really. The listener will work, but leave the user looking at the issue between create and the action of the listener.
I think you might be able to do something sneaky with javascript though - the code would run at the end of drawing the screen, and say something like "if previous screen was create screen, then issue a refresh". That should give the listener enough time to update the issue
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks. I think, that we should be fine even without javascript. While there are situations when issue page is automatically opened after creation, usually they are created via the quick create and that doesn't open issue right away - only shows the notification that the issue has been created :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.