What is included in "all issues fixed in this version" branch logic for a "Version released" trigger

[Jeff Post]

Looking at :
https://support.atlassian.com/cloud-automation/docs/jira-automation-triggers/#Version-created--updated--released I find I am unsure of how the release work and triggered automations interact as well as the definition of "all issues fixed in this version".

The manual process for releasing a version in Jira Software (cloud) using the Kanban Project template has options that configures that particular firing of the "Version released" event

. Specifically Jira asks if issues that are included in the version being released that are unresolved be moved to different, user selectable Version.

My confusion is with this paragraph: "You can use the Version released trigger together with the related issues branch Issue fixed in version to loop through all issues fixed in this version".

1. Does any automation configured as described above run before the unresolved objects are moved out of the version or after? In other words are the unresolved issues considered by the automation engine included in "all issues fixed in this version"?
2. Does the Resolution field play into definition of "all issues fixed in this version" I suspect it does but I cannot find any documentation on how? https://confluence.atlassian.com/cloudkb/best-practices-on-using-the-resolution-field-968660796.html

Thanks very much for your attention.
My goal with these questions is to create an automation that is able to send alerts on issues related to, issues that remain in the release AFTER all moves are completed, and the version is marked as released.

Note this question was also submited as page feedback for https://support.atlassian.com/cloud-automation/docs/jira-automation-triggers/#Version-created--updated--released

[Bill Sheboy · Accepted solution]

Hi @Jeff Post 

Regarding item # 1, my hypothesis is: because that dialog box has a cancel button, and "releasing" the version doesn't happen until the assigned issues are confirmed, thus once the rule is triggered the issues moved to another release are not included.

I just tested that and confirmed: issued are updated / moved to another release prior to the release changing status to "released" and triggering the rule.  And so they are not provided to the branch of that type in the rule.

Regarding item # 2, I am assuming this time you want to select the "Ignore unresolved issues".  In this case, anything assigned to the released version, resolved or not, will be found by that branch type in the rule.

For stuff like this which is not in the documentation, or is unclear, I recommend creating a test project and just trying it.

Kind regards,
Bill

[Jeff Post]

Thank You Bill!

I appreciate you testing and figuring out how question #1 works. Good advice to poke it and see what it does.   

for #2 actually I am wondering about how data in an issues' "Resolution"  Field impacts the list processed by the "all issues fixed in this version" branch.   If this field is Empty  (unresolved) there is a bunch of built in logic in JIRA that does not consider the Item complete, even if the status of the item is considered "Done". See https://confluence.atlassian.com/cloudkb/best-practices-on-using-the-resolution-field-968660796.html for Specifcs.  so in this case I am not concerned with the settings chosing for the Release Version screen at all. 

[Bill Sheboy]

Agreed: there is an opportunity to improve the language of that branch's name / description.

What I believe it actually means is "branch to any issues assigned to the version released (for the trigger) based upon the Fix Versions field".  It has nothing to do with resolution or if the issue was actually completed.

The dialog box for Release Version helps, as hopefully teams pause and think about any unresolved / incomplete issues prior to release.