Context
We use fixVersions for two purposes:
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:
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
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:
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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:
Check this rule out and see if it does the trick.
Regards,
Earl
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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:
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.