Change Parent Due Date

[tracey.fudge]

I would like to adjust the parent due date based on a child issue due date being changed (for the future only).  Does this look right?  I am not sure how to test this so I created a campaign with my name to filter out just that campaign.  

[Trudy Claspill · Accepted solution]

Hello @tracey.fudge 

What is the Parent/child relationship between the issues? Are they Epic and Child Issues? Are they Subtasks and parent issues?

Have you tried executing the rule by making a change to the due date of the "child" issue? Did it work as expected?

[tracey.fudge]

The sub tasks are listed as "child issues".

[Trudy Claspill]

Are you working with issue in a Team Managed project? I think you are, but I want to confirm that.

Have you tried executing the rule by making a change to the due date of the "child" issue? Did it work as expected?

[tracey.fudge]

I did make a change to the child issue and the date at the parent level did not change.  I am not sure if it is team managed or not.

[tracey.fudge]

Here is another view of my logic.

[Trudy Claspill]

When you are viewing the project look at the bottom of the navigation panel on the left. There is will say "team-managed" or "company-managed".

Rules have an accompanying Audit Log.

If you click on this it will show you a list of entries for each time the rule was changed/published and each time it executed.

If the Status column says "Config Change" that is a record for the rule having been edited and published. The other entries will be for times the rule executed.

Find the entry that corresponds with when you made the change to the child issue. Click the "Show More" link to the right of that entry. That will show the log details for that time that the rule was executed. Please share those details with us.

If all you see are entries with the "Config Change" status, then your rule has not executed. That would occur when the there has been no action that corresponds to your rule's trigger in the project to which the rule is attached.

Another debugging trick is to use the Log action. You can use that action to print text into the Audit Log and to print smart values. That can be very useful to show you what the values actually are and can offer a clue about why results did not turn out how you expected.

[tracey.fudge]

It says Team Managed.  And all I see are config changes.  See attached. 

[Trudy Claspill]

That is an indication that your rule is not being run.

Can you show us an issue where you changed the Due Date? I'd like to be able to see the Due Date field. Other information can be obscured.

I suspect that the "due date" field used in your issue is not the same as the "Due Date" field you selected in the rule trigger.

In your trigger if you search for just "due" for the field to monitor, do you get multiple matching fields named "due date" with variations on capitalization?

[tracey.fudge]

Yes I get multiple 'due' options.

[tracey.fudge]

[Trudy Claspill]

You need to select the one that matches the field you see on the screen. Make sure the capitalization matches. Matching capitalization will also matter when you try to reference a field in a smart value.

[tracey.fudge]

I made the change, adjusted the date in the child issue, but the parent date did not change.  Also the add value to audit log is not displaying in the log.

[Trudy Claspill]

Hello @tracey.fudge 

It can help rule debugging to map your rule components to the output messages in the log.

Reviewing the rule flow:

Issue CR-1693 is the issue where the Due date field was changed, causing the rule to trigger.

The next step in your rule branched to CR-1693's Parent issue (For Parent) to execute some actions. The actions indented below that are being applied to the parent issue CR-1687.

The log shows that it tried to edit the Parent issue but you say you saw no change. There are a few things I would say need to be reviewed.

1. Please share the details of the Edit step to show us the value you are trying to assign to the Due date field.

2. Use the Log Action to log the values you are using in the Compare step to confirm that it is comparing the values you think it should be comparing.

Regarding the fact that the Add value to audit log step didn't appear to do anything:

When you get to the If: Sub-tasks present step notice that is not indented under the For Parent step. That means the If is being applied to the issue that triggered the rule - CR-1693. CR-1693 itself is a sub-task, so the check to see if the current issue (CR-1693) has sub-tasks fails. Since that check fails, the next step is not executed at all. The logic is "if X is true, then do Y". X was not true so Y is not done.

Also, just for clarification, what are you trying to do with the part of the rule that starts with the  If: Sub-tasks present step?

[tracey.fudge]

1. Please share the details of the Edit step to show us the value you are trying to assign to the Due date field. 

MY RESPONSE:  See attached

2. Use the Log Action to log the values you are using in the Compare step to confirm that it is comparing the values you think it should be comparing. 

MY RESPONSE

I edited the the log to include the items to be compared: {{issue.Due date (duedate)}} {{triggerIssue.Due date (duedate)}}   and I am also asking for {{reporter.displayName}} and {{issue.assignee.displayName}}. 

So the entire thing is {{reporter.displayName}} and {{issue.assignee.displayName}} see {{issue.Due date (duedate)}} {{triggerIssue.Due date (duedate)}}.

But I do not see it in the log itself.  Where do I find that?

And I made edits to a child date and the parent did not change.

I DO NOT UNDERSTAND THIS:

Regarding the fact that the Add value to audit log step didn't appear to do anything:

When you get to the If: Sub-tasks present step notice that is not indented under the For Parent step. That means the If is being applied to the issue that triggered the rule - CR-1693. CR-1693 itself is a sub-task, so the check to see if the current issue (CR-1693) has sub-tasks fails. Since that check fails, the next step is not executed at all. The logic is "if X is true, then do Y". X was not true so Y is not done.

[tracey.fudge]

Regarding the question "Also, just for clarification, what are you trying to do with the part of the rule that starts with the  If: Sub-tasks present step?"....

MY RESPONSE:

All I am trying to do is adjust the parent due date based on the soonest child issue due date being changed. That way when we are scrolling through the lists of campaigns we see the right dates.  Most of us are in the child task, not the parent.  Can I be sent one that I can just copy?  

[Trudy Claspill]

1. Regarding the Edit Action step where you are trying to set the Due date within the For Parent branch, you have specified the wrong source for the data.

Because you are within a branch the context of "current issue" is changed to mean the issue being acted on in the branch. If you click where I'm pointing in the image above, you should get a pop-up that allows you to change that to "Trigger Issue". You want to copy the date from the issue that triggered the rule to run.

2. Adding log messages with the smart values from the Compare is showing nothing in the log.

That is because you added the statement for logging the message after an IF condition, and the IF condition is not met. The IF conditions says "If subtasks are present". Based on the location of that statement in your rule that condition is checking to see if the issue that triggered the rule itself has child subtasks. It is a subtask issue that triggered a rule, and a subtask can't have child subtasks, so this condition fails. The step to log messages will execute only if the condition passed. In this rule, that condition in that place in the rule will never pass. 

Try moving the Log action to the location indicated by the error (move it within the For Parent branch).

When you create a rule, there is a trigger. Something happens to an issue that matches that trigger. When the rule starts to execute, all actions that are aligned on the main line of the rule will be applied to the trigger issue.

The "For Parent" action is saying "for the parent of the trigger issue". The "If: Sub-tasks present" condition is saying "if the trigger issue has sub-tasks".

The context changes when you use a branch. Notice the two conditions and the Edit Issue action that are indented under the "For Parent" step. They are not on the main line of the rule. The indentation indicates that those steps will be applied to the issue(s) identified by the branch; in this case the Parent of the trigger issue.

When you add a condition (a Comparison or an If step) the actions that follow it in the same line will execute only if the condition passes. Within the "For Parent" branch the Edit Issue action will happen only if the two conditions before it pass. Below the branch the "Add value" step will be executed only when the "If: Sub-tasks present" condition passes.

Based on your last comment explaining what you are trying to do, you don't need the "If: Sub-tasks present" step at all. The For Parent branch will do what you want when we ensure that the steps in it are using the right smart values.

I can't provide a rule that you can just copy because I don't have the same fields in my system that you have. At this point your structure is correct (minus the "If: Sub-tasks present" step). We just need to get the correct smart values, and those are specific to your system.

[tracey.fudge]

Here is my progress and more question(s):

THIS WAS DONE (SEE ATTACHED): 

Because you are within a branch the context of "current issue" is changed to mean the issue being acted on in the branch. If you click where I'm pointing in the image above, you should get a pop-up that allows you to change that to "Trigger Issue". You want to copy the date from the issue that triggered the rule to run.

THIS WAS DONE (SEE ATTACHED): 

Try moving the Log action to the location indicated by the error (move it within the For Parent branch).

NEW QUESTIONS: 

1) We only want the parent date to change to a future date, not a date in the past.  Right now the parent date is changing to any new date applied (even in the past)

2) Also, we want the parent date's to change to the 'nearest' due date of any child issue.

3) Can this be set to run on all existing parent tasks as-is, even with no 'new' date entered?  I am testing mine to see if this works, but I am curious if we can run this (once the above #1 and #2 are applied) to all parent tasks.

4) Once testing is done, do I just delete the step "campaign name contains tracey"?

THANK YOU!!!

[Trudy Claspill]

1) We only want the parent date to change to a future date, not a date in the past.  Right now the parent date is changing to any new date applied (even in the past)

Your comparison is checking only if the trigger issue due date is later than the parent issue due date. If you want to also make sure the date is in the future compared to today, that would require another comparison of the trigger issue date to today.

2) Also, we want the parent date's to change to the 'nearest' due date of any child issue.

That is a new requirement you have not previously mentioned. Please define what "nearest" means, providing samples of dates that are currently assigned to the parent issue and subtasks, and then what the change should be when subtask ABC-123 has its date changed.

3) Can this be set to run on all existing parent tasks as-is, even with no 'new' date entered?  I am testing mine to see if this works, but I am curious if we can run this (once the above #1 and #2 are applied) to all parent tasks.

As-is? No, because as-is means without changing the trigger, and the trigger is set so the rule runs only when a date is changed. If you want to run it against all existing issues that have subtasks to get all of the parents updated to the current 'nearest' due date, that would require a different rule.

4) Once testing is done, do I just delete the step "campaign name contains tracey"?

Yes, if you want it to update any parent issue regardless of what is in the campaign name.

[tracey.fudge]

Is this correct for your response (see image)?

Your comparison is checking only if the trigger issue due date is later than the parent issue due date. If you want to also make sure the date is in the future compared to today, that would require another comparison of the trigger issue date to today.

That is a new requirement you have not previously mentioned. Please define what "nearest" means, providing samples of dates that are currently assigned to the parent issue and subtasks, and then what the change should be when subtask ABC-123 has its date changed.

My response:  If one child is due 5/25 and another is due 5/26 and another is due 5/27, we want the parent's due date to default to the soonest date of 5/25 (versus the later ones).  Does that answer?

[Trudy Claspill]

Is this correct for your response (see image)?

No, the additional Advanced Compare Condition should have "greater than" as the condition, and the second value should be now()

My response:  If one child is due 5/25 

Based on the new requirement, I would structure the rule differently.

In the branch the first step is now to look up all the issues that are children of the Epic and that also have a due date set in the future. 

The next step ensures that you have found at least one such issue.

If you have found at least one such issue, then the due date of the Epic will be set to the "minimum" due date from among the retrieved child issues.

If no child issues are found with a due date in the future, then the Epic due date is not changed.

You had a step in your rule to ensure that the new date you assigned to the Epic was farther in the future than the one it already has. 

Let's say your Epic had three child issues with due dates of 6/24, 6/25, and 6/26, and your Epic's due date was currently set to 6/24. If you changed the due date on the 6/25 issue to 6/23, would you want the Epic changed from 6/24 to 6/23?

If the answer is "no", then you would want this additional condition.

[tracey.fudge]

I did the changes you suggest (or so I thought).  See image:

But it did not work....All of the dates (for parent and child) were set to July 31st.  I changed a child date to July 15 and the parent date did not change.  See image:

[Trudy Claspill]

If a rule doesn't execute the way you expect, seeing the Audit Log information for the execution of the rule is very helpful to figure out what actually happened. Can you share that information with us?

<EDIT>

Right after clicking Publish I saw the problem.

The comparison value should be 0 not now()

[tracey.fudge]

Trudy - you are the BEST.  It worked.  It worked.  It worked.  So happy. THANK YOU.