Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Propagating a fixVersion change for an Epic to its children using automation

Kris Vandebroek February 1, 2022

Context

We use fixVersions for two purposes:

  1. For roadmap planning of (functional) releases. Every epic & story in an epic is assigned the fixVersion of the release they will be part of. This allows us to use the Roadmap functionality to quickly see what is left for that release.
  2. For technical release notes, when a story is implemented and the code is merged a technical fixVersion is assigned to track the technical releases and generate release notes.

We want to make sure that if Epic A is assigned fixVersion X, that all tickets in that Epic also have fixVersion X. When the Epic changes fixVersion to Y, we want all tickets in that Epic to have fixVersion X removed and Y added.

Question

I'm trying to create an automation rule that when the fixVersion of an Epic changes, removed the old fixVersion from the children and adds the new fixVersion to the children. I don't use the 'copy fixVersion from parent' because I don't want to overwrite the technical fixVersions that have been additionally assigned to the stories.

Following the documentation I found here and here, here's my last attempt:

Screenshot 2022-02-01 at 11.39.17.png

1. When the fixVersion changes => This should give me access to {{fieldChange}}

The changed field value will be available anywhere smart values are supported using the {{fieldChange}} substitution. Use {{fieldChange.fromString}} and {{fieldChange.toString}} to access display values and {{fieldChange.from}} and {{fieldChange.to}} to access raw values (for a select field for example). {{fieldChange}} will only contain the first changed value. If multiple values are changed (e.g. when setting multiple Fix Versions) then you can iterate over these using the {{#changelog.fixVersion}}{{toString}}{{/changelog.fixVersion}} expression.


2. Using advanced fields it should be possible to create a json in which you can specify which fixVersions need to be added to the multiple value list and which should be removed. I tried different notations, but each time I get the error "invalid json" when the automation rule is triggered.

Does anyone know how I can remove the old values of the fieldChange and add the new values of the fieldChange for this multi-valued field fixVersions?

Thanks

 

 

 

1 answer

1 accepted

0 votes
Answer accepted
Earl McCutcheon
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 9, 2022

Hello @Kris Vandebroek ,

Thanks for reaching out.

Replacing the fix version can be simplified a lot and acomplished without an advanced rule by selecting the "Copy From" variable and setting it to "Epic Issue" and then deselecting the "Add to Existing values" option like this:

Screen Shot 2022-02-09 at 2.28.11 PM.png

When the Add to existing values is selected the version will be appended to the fields existing values but when unchecked it will replace the value in the field with the new value and remove the pre-existing values.

Regards,
Earl

Kris Vandebroek February 10, 2022

Hi @Earl McCutcheon ,

Thanks for replying.

When using the suggested approach, only the new value is added to the child ticket, but the old value is not removed.

Example: Epic have Fix Version X and the Story in the Epic is following that and has Fix Version X. When I change the Epic to Fix Version Y, I also want to Story to go to Fix Version Y. Fix Version Y has to be added (this is done with your suggestion), but Fix Version X has to be removed as well. Do you see a solution for this?

Thanks

Earl McCutcheon
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 10, 2022

Hi @Kris Vandebroek ,

The existing value should be overwritten and replaced with whatever value is on the epic when the option "Add to existing values" is not selected.  

And testing this out in a staging instance I am getting the result of the value being overwritten as opposed to appending so that the fix version is matching the value on the Epic issue without the original value remaining.

 I made a quick video here showing the result.

Can you verify that the check box is deselected?

Regards,
Earl

Kris Vandebroek February 11, 2022

Hi Earl, 

Thanks for taking the effort to investigate and make a video of it.

Both suggestions are very interesting, but don't solve the initial problem case. Looking at my initial question, I want to have a functional fixVersion on an Epic indicating in which functional release the Epic is delivered and I want to version to stay in sync with the child issues. So if the Epic changes functional fixVersion, then the children should follow. => This can be solved with your last suggestion. However, I also want Stories to have a technical fixVersion indicating what was the first technical deployment that included this Story.

The problem with your first solution is that it would remove the technical version on the Story when the functional fixVersion changes on the Epic, because you overwrite the fixVersion on the children.

The second solution would keep the technical version on the Story, but it would not remove the old functional fixVersion X when the Epic changed from X to Y. With the second solution, the Story would have fixVersions X, Y and tech-release1.1. Because only the new fixVersion of the Epic is appended.

Kind regards

Earl McCutcheon
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 14, 2022

HI @Kris Vandebroek ,

OK got ya!  thanks for the clarification.

First off there is a BUG that is preventing you from using the changelog "to" and "from" string values on both the "Fix Version" and the "Components" fields,  Full details on the bug can be seen below, make sure to add yourself as a watcher to get updates:

However, I came up with a workaround that should do the trick for your use case.

I created another video viewable here  for a quick visual aid but the rule breakdown is as follows:

  • WHEN: Value changes for
    • "Fix Version"
    • Any changes to the field value
  • IF: Issue Matches JQL
    • issuetype = epic
  • THEN: Create Variable
    • Variable name: TempFix
      • NOTE: this can be any name that you want without spaces, just use your custom name to replace TempFix in the following rule
    • Smart Value:  {{fieldChange.toString}}
  • BRANCH FOR JQL:
    • Type of related issues: JQL
    • JQL: issuetype = story AND status in ("To Do","In Progress")
      • NOTE: Edit the JQL query as needed for your use case, I used the above JQL to avoid changing fix version for child issues that are already in the "Done" Status, but your statuses or needs may vary depending on the workflow
  • THEN: Edit issue fields
    • choose the Fix Versions field
    • and set the value to "SET VALUE" from the three-dot drop-down menu
    • use the variable SmartValue created in the step above: {{TempFix}}
      • NOTE: You will have to paste the string "{{TempFix}}" into the option field to be able to select the smart value as it will not display as a selectable option in the dropdown until doing so

Check this rule out and see if it does the trick.

Regards,
Earl

rburra April 18, 2022

Hi Earl,

This works but replaces the entire fixversion string with the new value.

 

My use case is as follows:

- If the Epic's fixversion is set to "String-version-number" i.e) the fixversion is starting with a String

- Then append "String-version-number" to the child tickets.

The child tickets may already have some fixversions which should not be replaced. And the Epic may have multiple versions but not all should be propogated only the ones starting with String should be appended.

 

Thanks

Ratna

Earl McCutcheon
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
April 19, 2022

Hello @rburra ,

Thanks for reaching out, some clarification would be nice here.

For the original use case in the above rule we set this up with the intention to overwrite the field with only the latest fixVersion, and that is covered in the step where we noted Unchecking the value "Add to existing values" touched on in this screenshot reposted from earlier:

Screen Shot 2022-02-09 at 2.28.11 PM.png

And the behavior is If this value is Checked it will add the new value to the field but leave the existing values, However, we set this up unchecked with the intent to overwrite the existing values with only the new value.

I believe all you need for your setup is to check that value and you should be all set, the preexisting fix Version will be left in the field and new ones will be added in.

Regards,
Earl

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
TAGS
AUG Leaders

Atlassian Community Events