deletedFieldChange doesn't remove label from Linked Epic

[George Tsemberlis]

Hi there

Trying to write some automation for when a label is removed from a story from the "StoryLabels" field, it removes the identical label in the "EpicLabels" field. 

In testing for a StoryLabels field containing "LabelA", "LabelB", and "LabelC", none of these are getting removed from the linked EpicLabels field

I have a branch for the parent Epic to ADD/REMOVE the EpicLabels field with the {{deletedFieldChange.values}} smart label but nothing is removed. In the audit log {{deletedFieldChange.values}} returns all three labels from the StoryLabels field. 

What am I missing here? 

[Bill Sheboy]

Hi @George Tsemberlis 

First thing, when you describe the "EpicLabels" and "StoryLabels" fields, do you mean custom fields with those names or do you mean the built-in Labels field in the Epic and Story, respectively?

Next, your rule is using a Field Value Changed trigger for the "Versions Ordered" field.  That means any changelog entries inside of the rule only refer to that field, and not other fields, like Labels.  To detect changes to the Labels field, that would be used in the trigger instead.

Kind regards,
Bill

[George Tsemberlis]

I mean custom fields with those names. "Versions Ordered" is a custom label field specific to stories.

[Bill Sheboy]

Thanks, and as I noted earlier: the changelog smart values only have data for the changed field(s), and so the trigger on Versions Ordered will not provide changelog data for your EpicLabels and StoryLabels custom fields. 

Your trigger would need to be on changes to StoryLabels to do what you asked.

[George Tsemberlis]

It is. "Versions Ordered" is the "StoryLabels" field in this example. My field routing is correct just for whatever reason the smart value is returning all the labels in the field and not removing just the one I want. 

[BHANU TEJA]

Hi @George Tsemberlis 

Please find the attached screenshots it might help you

use Global Automation

[Bill Sheboy]

George, would you please confirm if you want the fields synched / duplicated between the Story to the Epic, or do you just want the additions / deletions copied (allowing the Epic to have more values than the Story)?

And, please show images for the details of your edit issue action and the audit log details for the rule execution.  Those may provide additional context.

Hi @BHANU TEJA -- A rule like this should only be global (or multiple-project) in scope when necessary.  Otherwise it opens an instance up for potentially unexpected changes and excessive rule execution counts.  That second issue is particularly problematic given the changes in the limits for rule execution that take effect on 1 November.

[George Tsemberlis]

@Bill Sheboy Additions/Deletions copied as other stories attached to the epic will have different values

Screenshots:

1st Screenshot is the label field from the Story (Versions Ordered), i'm editing by just x-ing out the label I want gone

2nd screenshot is the audit log showing the {{deletedFieldChange.values}} output for the story label field

3rd screenshot is the rule component to edit the Epic Label field via removing the deletedFieldChange.values

4th screenshot is the Epic label field (Linked ISCIs), after rule execution,  still showing all 3 labels

1

2

3

4

[Bill Sheboy]

Thanks for that information, George.

Those smart values showing the additions / deletions appear to be text, and not lists of values.  Thus they need to be converted to lists for use in that action's add / delete of labels.

Please try adding a split() function call to do that, such as this:

{{deletedFieldChange.values.split(",")}}

And...you may want this to be conditional to prevent rule errors when either add or delete values are empty.  You could do that with rule conditions, or with smart value, conditional logic.

[George Tsemberlis]

@Bill Sheboy looks different in the smart value, but same results after adding the split call, nothing actually removed from the epic

 

[Bill Sheboy]

I did some retesting and found several problems with the changelog not correctly detecting list field updates, including for the labels, custom field type.  This reminded me of this open defect for the behavior: https://jira.atlassian.com/browse/JIRAAUTOSERVER-207 which also applies for Jira Cloud.

Short answer: I believe for this type of field you can only use a sync to match the issues (i.e., copy from) and not just update the delta-changes. 

[George Tsemberlis]

Well that's annoying and frustrating, sounds like it'll just have to be a one way add from stories to epic and any removal will have to be manual.