Appending story custom field to epic custom field

[Renee Tibedeau]

I've added the following automation to append value changes to Client Comm (custom field) in story tickets to the Epic ticket.

The problem I'm having is that if a value is added to Client Comm in the Epic ticket directly, the next time Client Comm has a value added in a story ticket it results in copying the full Client Comm back to the Epic rather than only the changed value. Any ideas to prevent this behavior are appreciated.

Steps taken to produce the behavior:

Added "Client Comm added in BA ticket #1" to the story ticket

Added "Client Comm added in Epic ticket" to the Epic ticket

Added "Client Comm added in BA ticket #2 (added after Client Comm added in Epic ticket)" to the story ticket - this resulted in "Client Comm added in BA ticket #1" copying to the Epic again which is undesirable

Desired Client Comm in Epic ticket:

Client Comm added in BA ticket #1

Client Comm added in Epic ticket

Client Comm added in BA ticket #2 (added after Client Comm added in Epic ticket)

[Daniel Ebers]

Hi @Renee Tibedeau

testing around a bit from what I could recognize the "changelog" always seems to contain the whole data - not just the most recent changed.

The following rule worked in a test so that there is no doubled entry - although it is a bit lengthy and complex and there might be edge-cases where it does not work well.

For the upper part:
1.) There is a variable holding the Smart value of

{{#changelog.Client Comm}}{{toString}}{{/changelog.Client Comm}}

...this is just to...

2.) "cut away" the previous data from field using "Edit issue" via

{{issue.Client Comm}}
{{myVar.substringAfterLast("\n")}}

For the lower part:

In case the field should be empty the value is just copied.

Please test if it fulfills your needs. Also, I am happy to learn about any simplification.
Please also check if edge cases that are not addressed using the above rule are critical - if so any other solution, or at least an improvement of above rule, would be needed.

Regards,
Daniel

[Renee Tibedeau]

Thank you Daniel. I tried to configure the rule as you showed above. It is not copying my client comm to the epic when I add it to a story ticket. Although the audit log says the issue was edited successfully. In my test, POC-198 is the epic and POC-199 is the story ticket. Do you see anything that I need to change in my configuration to match yours?

[Andy Heinzer]

Hi Renee,

I see that you're using Automation in Jira Cloud and trying to append custom field values from these stories to their parent Epic.  However it looks like the way your rule is currently written that this rule is also being run against the Epic itself as well as the stories in that Epic.  And since that Epic issue is also using the same custom field name here (Client Comm), then I believe the epic issue is copying it's current value into itself again here.

I think that is what you are trying to avoid.  So if you do not want this rule to run against Epics, then you can add in a condition before your branch in the automation rule.  For example, I created this one:

This condition uses an "Issue Fields condition" to see if the issue type does not equal Epic.  This way your rule can still run against other issue types, but won't be run against Epics themselves.

Does this help?  Let me know if this works for you, or if I have misunderstood the desired actions here within automation.

Andy

[Renee Tibedeau]

Thank you for your quick reply Andy. I tried adding that component to my automation, however, the behavior has not changed.

I have the Edit issue set as below. It is my understanding that the changelog should only copy the changed values. However, it is copying the full value from the story if the field has previously been modified in the Epic.

{{issue.Client Comm}}
{{#changelog.Client Comm}}{{toString}}{{/changelog.Client Comm}}

If we only ever add values to the story tickets in this field then the automation will work perfectly. It's when a value is added directly to the epic in this field that the automation breaks and copies the full value of the story field the next time it is modified rather than only copying the modified value.

[Andy Heinzer]

Thanks for the additional info Renee.  I tried to setup my own project with the same kind of rule, but so far I have not been able to reproduce your behavior here.  I think I'm missing something here.  Could you go back to the automation rule in question, and then click the Rule details?  I'm curious if perhaps your rule has the "Allow rule trigger" enabled:

If you have this enabled, it certainly could be that some other rule is making changes to multiple issues at once.  I can see a scenario where if some other rule triggers this one for more than one issue in the epic at roughly the same time, what can happen is a race condition where both issues try to update the epic at the same time.  So first issue does a lookup of the current value for that field in the epic at the same time as the other issue does the same thing, but since the first issue updated first, the second issue doesn't make a second check of the previous value and just updates the issue with what it believes was the previous value.

Checking the audit log of the automation rule could probably give us more details about what is exactly happening here.  It might be this scenario I described here.  One thing you can try to do to avoid this problem is force the automation to do a lookup of the issue value before setting the value. This action is called "Re-fetch issue data".

With this action happening immediately before the edit, automation should then have a more accurate understanding of what the current value of {{issue.Client Comm}} actually is at the time this rule runs.

Try this, even if your rule is not using the "Allow rule trigger" enabled here, it is worth trying this adjustment to better understand if the cause of this is multiple issues running this automation at nearly the same time.  If this doesn't correct the problem, I would be interested to take a closer look at the audit log of this automation rule to see in more detail what values are being set by each execution of this rule in sequence.

[Renee Tibedeau]

I confirmed that I do not have allow rule trigger enabled. I added the re-fetch issue data action. I am still getting the same behavior. See below screenshots for my rule setup and audit log. 

[Andy Heinzer]

Hi Renee,

Thanks for all these screenshots and this information. 

I have tried to recreate the behavior you have here, but the closest I have come to being able to do this, is when I went back to edit the first stories' Client Comm custom field a 2nd time.  When I do that, I find that the entire new contents of that field on the story are being appended into the corresponding field of the epic.

But I do not believe that is what you are reporting is happening here. So far I have not found a means to reproduce the exact behavior you describe here.

I want to learn more about this environment to better understand the behavior here. At this point I believe there might be some other automation rule at play here OR there is something else different in your environment that we have yet to account for.  It is possible that there might be another project automation rule, or possibly a global rule that might also be setting that field on epic.  I would look to see if there are other automation rules in play here.

If you cannot find another automation rule in play here, one other means to try to troubleshoot this would be to change which field to copy data to on the Epic.  Since the issue field is same name in both story and epic and the reported problem appears to be happening only after changing the value directly on the Epic, let's try creating a new paragraph (multi-line text field) in this project for use only on the Epic issue.  This could be named something like "EpicClientComms".  If you try this, you would need to adjust the edit action of the automation rule to use that new field such as

{{issue.EpicIssueComms}}
{{#changelog.Client Comm}}{{toString}}{{/}}

I also feel like @Daniel Ebers line of reason is good here as well.  If the problem is that the changelog itself contains the full contents as opposed to the appended change, then creating a variable and using a substring function might be a better approach for what I think you want here.  However I am just a bit wary of trying to change lots of things at once without full understanding what is causing your behavior here.  I prefer a more methodical approach of making a single change and then test to verify results.