nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira Automation: Assigning a fix Version based on Component

Igor Strba

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:

there are two components in the project - "ABC" and "DEF"
there is a unreleased version for each component with naming convention [component] YYMM, i.e. "ABC 2108", "DEF 2108"

Any idea, help or guidance will be appreciated.

Thanks,

Igor

Accepted answers

All comments

Bill Sheboy

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

Igor Strba

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

Bill Sheboy

Hi Igor,

Other than a potential Y3K problem :^) I expect that if these two assumptions are valid:

you create the versions before you need them, and
the work is done *during the quarter for the release version* that...

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:

grab the component name, adding a space after it
grab the current date/time
convert the date time to jiraData format: 1979-11-01
remove any dash characters
and grab just the last 2 digits of the year and the month

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.

Igor Strba

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.

Best regards,

Igor

Kelly Arrey

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud

automation