How to keep version on specific issues when version is released

Alain BEAULIEU
Contributor
June 13, 2024

Hi,

This is a special/non-standard case.

When we release a version, this pop-up appears and we normally choose to push undone issues up to the next version:

2024-06-12_13-36-31.jpg

 

I want to create an automation rule triggered on the Version Released event. I want the rule to check every issue included in that release, and if the issue contains a given XYZ label, then do not increase the version number even if in the above screenshot the option to move unresolved issues to a given version is selected.

If that is not possible BEFORE the release, then AFTER the release I want the automation rule to check all the issues again but this time if the Labels field contains a label called ABC_STATUS, then:

  1. Remove the Resolution value in the issue;
  2. Return the issue to the ABC_STATUS status (a real status in our workflow);
  3. Revert the FixVersion to the one it had before the release. Note that our tickets have multiple versions in FixVersion (e.g. 9.30.001, 9.31.005, 9.32.002), so I only want the version concerned to be reverted.

Basically, I want some specially labeled tickets to not move when a version is released and I'm not sure how to use branching with the right conditions in Automation.

And I'm using Labels but it could be any field that might be used to identify and prevent these special issues to move up.

Ice cream cone to the first one with an answer.

2 answers

0 votes
Rick Westbrock
Contributor
June 17, 2024

Is there a project setting which causes that dialog box when manually releasing a version? I ask because I have an automation rule which releases the newest unreleased version every Sunday and for unresolved issues it just leaves them the version so it feels like the automation rule "Release version" action doesn't trigger that check for unresolved issues like manually releasing does.

If you have a sandbox tenant I suggest that you try building your automation rule there and testing to see that it works as desired as you may not have to even account for this special case at all. If you don't have a sandbox then maybe create a new version to use for testing this.

Alain BEAULIEU
Contributor
June 17, 2024

Interesting, but we wouldn't be shielded from someone actually releasing manually. Many people in our organization have the right to release versions. Of course we could document the new procedure in our process.

I'll give it a shot. Thanks for the suggestion @Rick Westbrock .

Rick Westbrock
Contributor
June 17, 2024

Ah I didn't consider manual releases because my team's projects all use automation rules to release our weekly versions. I know that you can access the previous value of a field when using something like ScriptRunner but I don't know if that's possible in automation rules. 

I have a feeling that you won't be able to check the labels before release because from what I have seen with automation rules they don't start executing until after the triggering event has completed in which case it's too late to check the labels.

While you can have the automation rule simply remove the new version to which the issue was added I have no idea whether the issue gets removed from the version which was released when the user selects the "Move unresolved issues to" option.

I guess another option would be to create an automation rule which does the following:

1. Presents a user prompt for the version name

2. Release the version entered by the user in step #1

Users would trigger that automation rule from any issue instead of using the normal process to release a version. I could see this causing some friction for your users but I think at least it would accomplish your goal of not disturbing the versions in the issues. The downside would be that if there are other unresolved issues in the version being released those won't get moved to another version either.

Alain BEAULIEU
Contributor
June 17, 2024

Thanks Rick. I spent all day today testing several solutions that would work while preserving the usage of the prompt. None of them worked. We're going to have to change our process to work around this issue I believe.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events