I have a rule that ensures the custom field "Delivery Stream" (customfield_10109) is updates all sub-tasks when the task/story value is changed. That works as expected.
However, there are conditions that can result in a sub-task not having the same value as the parent, e.g. when a subtask is moved to a different parent, or a task is demoted to a sub-task. Those events can't be caught with a trigger as best I can tell.
To cover those edge cases I had created a scheduled task to run every hour on changed tasks/stories (using JQL) and ensure the sub-tasks matched the parent, however this was failing if the Delivery Stream field had been cleared.
These are the 2 log lines I've used to try to capture the change, and the results in the logs from running the rule after setting the field to a value. These are the first steps immediately after the schedule trigger.
{{fieldChange}} # {{fieldChange.field}} ## {{changelog}} | {{changelog.field}}
{{issue.key}} {{issue.customfield_10109}} # {{issue.customfield_10109.fromString}}{{#if(issue.customfield_10109.isEmpty)}}EMPTY{{/}} > {{issue.customfield_10109.toString}}{{#if(issue.customfield_10109.isEmpty)}}EMPTY{{/}} | {{changelog.issue.customfield_10109}} . {{#changelog.customfield_10109}}{{fromString}}{{/}} >> {{#changelog.customfield_10109}}{{toString}}{{/}}
Log action
Log
# ## ChangeLogList{startAt=0, maxResults=0, total=0, histories=null} |
Log action
Log
DFXXSYS-44 Atlas # > | . >>
Help to correct my attempt to capture the change, or a suggestion of a better approach to solve the edge case are both appreciated
In automation rules, the isEmpty function does not appear to work consistently for all field types to detect a cleared field. Worse still, there are appear to be differences for null (i.e., the field value was never set) versus empty value (i.e., the field had a value and was cleared) for some field types.
I recommend experimentation with a test rule, checking with isEmpty, fromString, size (for selection fields or lists) and using if() to confirm the empty field detection works as you need.
Kind regards,
Bill
Hello @Dave Furlani
Can you describe the nature of the "failure" of the scheduled rule in more detail?
Is the rule not running at all?
Is the rule not picking up the issue as part of its JQL results?
Is the rule not updating the subtasks as it should?
Can you show us the audit log details for an execution of the rule where the "failure" occurred?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The rule runs but does not pick up the issues where the Delivery Stream field was emptied, and thus not progressing to clearing the sub-tasks either.
There is no error in the logs, the rule just doesn't do what it needs to
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Can you provide a screen image of the audit log? That will show us what the rule thinks it is doing and what issues it is trying to act against.
With that, can you provide screen images showing the complete rule? That way we can compare what is in the audit log to the steps in the rule.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I played with the rule and after still having no luck I disabled it. Here's the last log and the rule as I left it:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.