Hi gents,
I am strugling to find working solution for assigning a fix Version to resolved issue. The assignment should be based on component, as there are always two unreleased versions active - one for each component within the project.
The rule should check value of field "Resolution" during issue transition and for resolved issues (Resolution = Done) assign corresponding fix Version based on component.
"Edit issue" action does not allow me to set "Fix versions" to match pattern / regex. There is an option to specify additional field values to be set using a JSON object, but i was not able to find any example of pattern / regex usage within JSON in the documentation:
https://support.atlassian.com/jira-software-cloud/docs/advanced-field-editing-json/
To clarify the issue a bit more:
Any idea, help or guidance will be appreciated.
Thanks,
Igor
Hi @Igor Strba
You can edit an issue's fixVersion field, setting it to a smart value expression. When you select the field, just type in your expression.
And, assuming there is only one value in components, you can use your {{issue.components.name}} and add on your date information to build the version name for assignment. When there are more values in components, you will need to use list functions to first extract the value you want to use.
What you cannot do from smart values: look up in a list of versions to find one matching an expression. You will need to build the version name based upon other information, such as the current date/time.
Please look here for some information to get you started. If you get stuck writing your rule, please post and image of your rule, the audit log, and what you believe is not working as expected. Thanks!
https://support.atlassian.com/jira-software-cloud/docs/smart-values-general/
https://support.atlassian.com/jira-software-cloud/docs/smart-values-lists/
https://support.atlassian.com/jira-software-cloud/docs/smart-values-text-fields/
https://support.atlassian.com/jira-software-cloud/docs/smart-values-date-and-time-functions/
Best regards,
Bill
Hi @Bill Sheboy ,
Thanks for fast response.
I am afraid that i can not "build" the version name as it is predefined - four releases per year (February, May, August, Novmber), i.e. "ABC 2108", "DEF 2111", "ABC 2202", etc...
Key is to look up in the list of unrleased versions and select correct one by matching an expression (pattern) defined by {{issue.components.name}}. Thats where i am stuck as I was not able to find any example of pattern / regex usage within JSON in the documentation.
Best regards,
Igor
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Igor,
Other than a potential Y3K problem :^) I expect that if these two assumptions are valid:
You could build the version name from the component and {{now}} with the text and date functions.
{{issue.components.name}} {{now.jiraDate.remove("-").substring(2,6)}}
How this works:
Then, just past that expression in when editing the fixVersion field.
Restating my first comment, the smart value functions can help quite a bit...it often just takes some experimentation to get what you want.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Bill,
Thanks for the advice with chaining the smart value string functions.
The automation rule is triggered when resolution is set to "Done" which can be up to three months before actual release - i.e. issue resolved on 13th of May will be in August release.
Key is to look up in the list of unrleased versions and select correct one by matching an expression (pattern) defined by {{issue.components.name}}. Thats where i am stuck as I was not able to find any example of pattern / regex usage within JSON in the documentation.
Best regards,
Igor
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Igor, and thanks for clarifying your use case.
At this time, there does not appear to be a way to access a list of a generic data entity (e.g. Version) which is not associated to an issue. You can get such things as the version list from the REST API, and that can be called from an automation rule. However...
Here is what I still do not understand: how do you know which version to assign to from the issue? You posted:
The automation rule is triggered when resolution is set to "Done" which can be up to three months before actual release - i.e. issue resolved on 13th of May will be in August release.
There must be some piece of data in the issue to identify the release date, correct? If so, you could use that and the component to build the value to set in the fixVersion. If instead there is no value stored in the issue I do not see how this is possible to select the correct version.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm running into the Same Issue - it would be really great if we could just add a component to a release. that would easily solve my problem.
I was hoping to be able to look at a list of unreleased versions and pick one based on the component.
eg; we use platform components iOS and Android
When I create releases we put the component in like so
[iOS] 1.2.3
[AND] 2.1.3
These are never really in synch and release semvers are set depending on the type of work completed in any given sprint/initiative - this sprint is may be a patch or a minor version bump, next sprint it may be a major release. So these cannot really be generated through scripting.
Any thoughts of adding a component field to a release? That would solve this easy peasy.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
At this time, I do not believe you can associate extra data with a release and out-of-the-box Jira. You may want to check the marketplace for apps to enhance release management.
Your work-around of adding the component's name to the version name can work, but you cannot search for those with JQL until issues are assigned. The other way to get at the releases is using the REST API from the automation rule, as I noted earlier to Igor.
Kind regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Late to the party, but why replicate the component value in the fixVersion field? You can filter the tickets based on the component and fixVersion fields. I'd leave them separate. Just my $0.02.
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.