Jira advanced automation - How to change issue dates based on blocked by issues?

[jaime.gilmartinez]

Hi,

I need to create an automation in my Jira project that allows me to pick up the finish date of issues blocking another one and update the blocked issue to account for delays in its predecessors.

For example:

• Issue A: finishes 05/01/2023
• Issue B: finishes 25/01/2023
• Issue C: finishes 10/01/2023

All issues A, B and C block issue D, which currently starts on 27/01/2023 and finishes on 27/02/2023.

What I would like to do is set a trigger on issue D so that

• FOR linked issues (is blocked by) - so Issues A, B and C
• IF end date IS AFTER start date of current issue (Issue D)
• THEN create a smart value {{duration}} (finish date minus start date; of Issue D)
• EDIT start date (Issue D) to the MAX of Issues A, B and C finish date + 1 day
• EDIT finish date (Issue D) to start date plus {{duration}} smart value

Or in other words, if Issue A (or B or C) change their finish date to 05/02/2023 due to a delay, then Issue D start date would move to 06/02/2023 (05/02/2023+1), and a duration of 1 month (Original Issue D finish minus start dates, so 27/02/2023-27/01/2023) is added to this date to give a finish date of 06/03/2023

Getting instructions of completing this would be amazing please.

As a bonus challenge, I would like to create a notification or alert when changing any issue finish date (A, B or C) to after the blocked by issue start date (e.g. Issue A finish date changed to 28/01/2023), that

1. Informs that this has an impact on a blocked issue (Issue D), and
2. Asks to confirm whether we want Issue D dates to be moved accordingly (so whether we want to trigger the automation or not).

Thank you very much!!!

[Trudy Claspill]

@jaime.gilmartinez 

I think this will do it. I haven't actually tested this yet.

1. Trigger the rule when the Finish Date of an issue is changed.

2. Execute a branch to shift to the issues that are blocked by the trigger issue (if any).

3. Create a variable for the duration of the blocked issue

4. Lookup up all issues that are blocking this issue, ordering them so that the one with the latest Finish Date is first in the list.

5. Check that there is at least one issue in the result set.

6. Check that the Finish Date of that latest finishing blocking issue is later than the Start Date of the blocked issue.

7. If so, then update the Start and Finish dates in the blocked issue.

(1) TRIGGER: Field value changed: Finish Date

(2) BRANCH: For Related Issues / Linked Issues
  Link Type: Blocks

  (3) ACTION: Create Variable
    Name: dateDiff
    Smart Value: {{issue.Start Date.toDate.diff(issue.Finish Date.toDate).days}}

  (4) ACTION: Lookup Issues
    JQL: issue in linkedIssues({{issue.key}},"is blocked by") and "Finish Date" is not empty order by "Finish Date" desc

  (5) CONDITION: Advanced compare
    First value: {{lookupIssues.size}}
    Comparison: is greater than
    Second value: 0

  (6) CONDITION: Advanced compare
    First value: {{lookupIssues.first.Finish Date}}
    Comparison: is greater than
    Second value: {{issue.Start Date}}


  (7) ACTION: Edit issue
    Field: Start Date
      Value: {{lookupIssues.first.Finish Date.plusDays(1)}}
    Field: Finish Date
      Value: {{lookupIssues.first.Finish Date.plusDays(dateDiff)}}
    

For the bonus part, you could have an Automation rule that sends a notification instead of making a change, but I'm not sure of a way that a notification can "prompt" for a response that would then be able to trigger another automation rule. I will have to think about that a bit more.

[Bill Sheboy]

Hi @jaime.gilmartinez 

Adding to Trudy's answer...

There are some things to consider for your scenario, so please decide what you want to do for at least these cases:

• First thing: do you only care about the relative change in timeframes, or do you need to "remember" what were the dates of the original blocked item, issue-D?  If you need the original dates (e.g., to measure the amount of date churn) you will need additional custom fields to sort this out...making the rules more complicated.
• You do not note anything about issue types, only about linking and link direction (i.e., blocks and is blocked by).  With no other distinctions, that means the issues in your project could create both a loop and one which may not be resolvable easily with rules.  Please consider what you want to happen in such cases.
• In your scenario is is possible that different blocking chains are connected?  If so, your rules get more risky, as their changes may need to be self-triggering for other issues (i.e., with the "Allow rule trigger" option).  For example,
  • A, B, and C issues block issue D
  • D, E, and F issues block issue G
  • E and H issues block issue J
  • ...

With your scenario you are essentially trying to re-create functionality normally in project management/dependency mapping tools.  As a result, you will need to decide what you want to handle, or not.

Kind regards,
Bill

[jaime.gilmartinez]

Thank you very much both!