I have a scenario where an issue is transitioned by user X to be reviewed by user Y, and then accepted or rejected.
When user Y have performed the review, he may need to transition the issue back to user X for more work, and optional he may select a different user to perform the work.
So I'd like to perform a pre-transition modification to the shown screen during the last transition, where user X is preselected in the assignee role, instead of the current default which have User Y selected.
If Scriptrunner can not do this, then what other options do I have?
Looking forward for your response.
As Mikey alluded to, I would recommend that using a behaviour is the easiest way to set this. The basic documentation on Behaviours can be found here: https://scriptrunner.adaptavist.com/latest/jira/behaviours-overview.html
The link Mikey gave to the ChangeHistoryManager is great, although it may be simpler to use a custom field to hold the value - I'll outline that option here for you. Basically, we generate a custom field called Review Requestor - a field which would be filled during the post function of the Request Review transition, and updates with the current user. To do this, first you'll need to get the current user, using a bit of code like this:
ApplicationUser currentUser = ((WorkflowContext) transientVars.get("context")).getCallerUser();
Next, using code similar to that shown here, you can set the field value (ensure you import the correct bits - you'll also need to grab ApplicationUser from com.atlassian.jira.user in order to be able to use the code mentioned above).
Once that's done, it's then a simple case of building the Behaviour. I would recommend starting with the example code here https://scriptrunner.adaptavist.com/latest/jira/behaviours-overview.html#_setting_a_default_description, and changing from description to assignee - basically, the plan is that whenever you open the assignee field for editing, it will attempt to set it to the value held in the Review Requestor custom field - that also means that you should clear the value from the Review Requestor field in the Post Function associated with the review completion (so it doesn't happen all the time from then on).
The reason I mention this is that if you end up with the reviewer changing during the review process (and thus the assignee getting updated), using the change history may not give you the result you're after (the original requestor). It's up to you how you want to implement - if you decide to go with the history one, the code for that should be included in the behaviour described above, along with a check to ensure that the behaviour only triggers during the appropriate transition (you can use code based on the examples here to implement that).
Hopefully that's given you an outline of how to get started, if you have any questions, please post them here.
Thank you @Jamie Sawyer [Adaptavist] - and also thank you @Mikey Schott [ServiceRocket] . I would have commented earlier, but my access level to this site is still too low to be allowed more than one comment per 24 hours. :-( Jamie, your answer was exactly what I was looking for, and will certainly help me (and many others) in the time to come. Best regards.
I think this is possible. What you're looking to write is a Behaviour associated with the Assignee field for the specific Workflow Action where you would like this to occur. You'll then have to write a serverside script for that Behaviour that uses the ChangeHistoryManager to find the previous value of the Assignee for that issue and update the screen to show that value.
Here seems to be an answer (albeit from a few years ago) where someone is getting the previous assignee using the ChangeHistoryManager: https://answers.atlassian.com/questions/82258/how-to-get-previous-assignee-of-the-issue And you can refer to Adaptavist's documentation for examples on Script Runner in general I would take it in phases. First see if you can get a Behaviour working that sets the Assignee field to a specific default value of your choosing. Then see if you can retrieve the previous Assignee using the ChangeHistoryManager. And then finally put those two pieces together.
It started as any story starts, on a normal, rainy day. Admin meets App, and her name was Klok2, and like any first relationship we were both trying to make it work but neither one knew what...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs