We are trying to auto-populate the Affects Version/s field with the related component version based on the Bundle name entered in a Bundle Name field (Raised in Version) and the component selected.
For example, a user creates a JIRA ticket with a Raised in Version (Bundle Name) of R2170, but no component has been selected at the time of ticket creation.
A user then edits the ticket and selects the Installers component, which had a component version of 2.16.0 for the R2170 bundle.
So instead of the user then having to manually select the 2.16.0 version for the Affects Version/s field, we want to auto-populate the Affects Version/s field with the Installers component version 2.16.0 that was included with the R2170 bundle name.
Basically, enter bundle name in custom field, select component and then auto-populate the Affects Version field with the component version that was included with the bundle name.
I tried using the following, but returned null for uri:
JIRA Software 7.4.4
Final version of the script, which sets affects version field based on currently selected bundle and component. You need to update custom field name to customfield_12252
Thanks for the quick response Deniz. Script works great when updating components and release bundle, but just thought of a scenario that slipped my mind earlier. After the initial Affects Version is populated based on component selection and bundle name, we still need to be able to add other Affects Version/s, which could make things a little more difficult running as an update issue listener.
For example, Release Bundle is R2170 and Installers is selected for component, so the Affects Version/s field is initially populated with 2.17.0. Then the Product Owner determines that the issue also affects an older version of the component that we now need to hot fix, so they manually add 2.15.1 to the Affects Version/s field, which of course is considered an update, so the listener script executes and resets the Affects Version/s field to 2.17.0 only based on the Release Bundle and the Installers Component.
Have to think about this some more, but maybe we change the script so that it adds to Affects Version/s field, rather than replaces, and then if the Product Owner needs to cleanup any invalid versions, they can do it manually at that point.
Thanks for your support,
I dont have access to my computer now so I cant try it. But you just need to get affects version field (an array of versions) at the beginning of script. This is shown in my previous script. The method that sets affects version accepts list of version, so you need to pass both component version and previous versions combined. It should work.
Here is the version that adds new version to existing list of versions instead of replacing it. Also may be you should need to consider the case when multiple component is selected. Current script assumes only one component is selected and works for first component of issue.
Hi Deniz, you rock! I think this version will accomplish what we need. As for multiple components, we are actually going to implement a process where if the code changes needed to resolve a ticket will touch multiple components, then we will create subtasks to cover the development work needed for each component , so I think we will be OK.
Thanks again for all of your help. I am going to play around with the script some more today and may have a couple of questions for you later because I really want to understand the magic behind the groovy script.