nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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)

Accepted answers

All comments

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:

Screen Shot 2021-09-01 at 3.05.17 PM.png

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.

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:

Screen Shot 2021-09-02 at 3.51.36 PM.png

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".

Screen Shot 2021-09-02 at 3.59.02 PM.png

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.

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

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.

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?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Unanswered
Groups
Help

Find more posts tagged with

cloud

jira-software

jira-software-cloud