Add multiple fix versions to linked issue and project

[Steve Rhodes]

I'm trying to close an issue in one project when the other one closes. However, it needs to have the same fixversion. Currently, if there is one fixversion on the trigger issue, and this doesn't exist in the linked project, it is created and added to the linked issue.

The problem arises when there two or more fixversions in the trigger issue. It creates a fixversion in the linked issue project which is comprised of all of the fixversions, concatenated.

To bypass this for now i'm checking {{issue.fixVersions.size}} (for amount of versions =1) and then creating a new version with {{triggerissue.fixVersions.name}}.

So basically, in the trigger issue if theres more than 1 fixversion I think it needs to split them and create them in the linked project and add them to the linked issue. I feel that this should be possible in automation without using a marketplace addon (before someone from codefortynine jumps in).

I would appreciate some help with this, as its a real headscratcher.

[Bill Sheboy]

Hi @Steve Rhodes 

Without seeing your entire rule for context...

I wonder if you can use an Advanced Branch over the Fix Version values to do this: https://community.atlassian.com/t5/Automation-articles/Branching-over-smart-values-in-Jira-Automation/ba-p/1741935

Please note branches like this execute in parallel and asynchronously. So for your scenario consider how to use the distinct values if this is spanning multiple issues and versions to prevent collisions and race-track errors.

If that was unclear or does not work, please post an image of your entire rule and an image of the audit log details showing the rule execution.  Those will provide context for the community to help.  Thanks!

Kind regards,
Bill

[Steve Rhodes]

I have made some adjustments after following the docs you suggested. However, now instead of creating the new release in the target project, it creates one large release in the format of [{ "name": "M 2023.10" },{ "name": "M 2024.04" }]" where "M 2023.10" is the existing one that exists in both projects and and "M 2024.04" is the release that only exists in the source project. The create variable uses the smart value: {{issue.fixVersions.asJsonObjectArray("name")}}

This results in the following:

instead of creating the M 2024.04.

[Bill Sheboy]

Before continuing I want to check something: is your intention to create one version in the other project or multiple versions, based on matching values?  

If it is creating multiple versions, I do not believe that is possible with automation rules, as branches cannot be nested and there is no REST API function to create multiple versions at one time.

If it is creating on version, how do you know which one to create, based on the trigger issue?

[Steve Rhodes]

I think the team rarely have more than 2 releases and its most common that one of them already exists in the destination (either that or there is one in the source and none in the destination), therefore I'd suggest that this automation is to add a version to a project and then to the issue when there is already another version in the issue. I doubt that it would be required to process all the versions in the source and iterate through the list and add them to the destination project and issue.

[Bill Sheboy]

It seems the challenge is still the need for nested branching (with version values and linked issues) which is not possible in rules.

A possible work-around would be to do this in two rules, where one triggers the other:

• First rule, triggered when the issue transitions to done, creates the versions in the other projects...and as the final rule step, sets a field (or adds a special comment, etc.) to the trigger issue
• Second rule, triggered on that final condition from above, would then iterate over linked issues and add the versions (assuming they had been added successfully).  That version add operation will need to be done with advanced edit with JSON to handle one-to-many versions.  This rule will need to have the "Allow Rule Trigger" option enabled to allow the actions of the first rule to trigger this one.

This is a quite unique scenario, and I have not tried implementing this.  And so I recommend testing this one thoroughly to prevent problems down the road.