You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
Next: Root
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
I have Request Type where I want to set the values of certain fields based on the reporter. This all works fine if I assume that the logged-in user is the Reporter. However, if a Service Desk Agent selects a different user from the "Raise this request on behalf of" field, I want to capture that value and use it to populate the fields on the Request.
Is there a way using a ScriptRunner behavior to get the value of the "Raise this request on behalf of" field?
UPDATE WITH SOLUTION: The "Raise this request on behalf of" field can be retrieved and managed as getFieldByName("Reporter")
To answer your question, Behaviour will not be the best solution for this scenario. It would be better to use the Post-Function instead, i.e. for the Create transition.
Also, it would be best to upgrade your ScriptRunner plugin to the latest release, i.e. 7.13.0 and use the HAPI feature, which simplifies much of the coding.
Below is a sample working HAPI code for your reference:-
Issues.getByKey(issue.key).update {
setCustomFieldValue('Sample Text Field', issue.reporter.displayName)
}
Please note that the sample working code above is not 100% exact to your environment. Hence, you will need to make the required modifications.
Below are a couple of screenshots of the Post-Function configuration.
1. In this example, the Create transition adds the Post-Function.
2. The Custom script Post-Function is used as shown in the screenshot below:-
3. The Custom script post-function view:-
Below are a couple of test screenshots for your reference:-
1. First, I am creating a Technical Support ticket.
2. Currently, the Raise this request on behalf is set to the user I have logged in as
3. I updated the Raise this request on behalf of the field to Max Peterson and filled in the Summary and Description. Currently, the Sample Text Field is empty
4. Once the ticket is created as expected, the Sample Text Field value is set to the reporter, i.e. Max Peterson and not the logged-in user.
I hope this helps to answer your question. :-)
Thank you and Kind regards,
Ram
@Ram Kumar Aravindakshan _Adaptavist_ I appreciate the answer. However, I want to pre-populate the fields with current information on the form so that the user can then change the values that they want to change when they create the ticket. I want the agent to see the values associated with the person that they have selected, not the values associated with themselves.
For example (not a real example, an illustration), I have a Name, Phone Number, and Date of Birth change request. I want the user to see the current values that are in the system for them before they make the change, so I pre-populate those fields on the form. They can change what needs to be changed and leave the rest of the values alone. They submit the ticket and my workflow handles the changes. In this case, I know who the user is because I can get it from the currentUser() API.
The problem is when a user calls in to the Service Desk and says "I am John Doe and you have my Date of Birth wrong". The agent opens the form. Using the currentUser() API, I fill in the ticket with the Agent's information, not John Doe's information. That is fine if, when the agent selects John Doe from the "Raise this request on behalf of" field, I can re-populate the form with John Doe's information. However, I don't seem to have a way to get the value of that field or trigger on it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I did a quick check with the development team they mentioned that the Raise this request on behalf of should contain the details of the user that has been set for that field.
Since it still contains the currently logged-in user's details, it seems to be a Bug.
I suggest that you raise a Bug ticket in the Adaptavist support portal.
Thank you and Kind regards,
Ram
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Ram Kumar Aravindakshan _Adaptavist_You answered my question, which is that it isn't a bug. I just wasn't retrieving the field correctly. Once I changed my script to retrieve the field as "Reporter", it worked as expected. Maybe worth adding that to the documentation somewhere? Or maybe I missed it?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
To my knowledge when agent uses "Raise this request on behalf of" field to create a case in JSM, the field itself it is still the actual reporter field in the system. It is not a different field. I am surprised that ScriptRunner for Jira will behave differently. Unless in your behavior setup, you are pulling the current logged in user information.
I would suggest that you also reach out to ScriptRunner vendor for their input on this matter. Their support is very good on responding to issues with the add-on.
Hope this helps.
Best, Joseph Chung Yin
Jira/JSM Functional Lead, Global Technology Applications Team
Viasat Inc.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Joseph Chung Yin Thank you for your answer. You are correct, that field populates the Reporter when the form is submitted and the issue is created. However, until the form is submitted, there is no Reporter. I need to know the value of that field so that I can pre-populate values before the form is submitted.
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.