How do I update Baseline Dates based on FixVersion Dates?

[Isabella Musial]

I am attempting to run an AUTOMATION RULE so that when the fixVersion on an issues is empty THEN the FixVersion is added to said issue, THEN the Baseline start date is updated to the FixVersion start date, and the Baseline end date is updated to match the FixVersion release date. So: 

1. Create new Rule using Trigger: Field value changed for FixVersion on Edit
2. Branch Rule: 
   
   1. If JQL matches: Team = 1080 AND issuetype in (Epic, Milestone, Capability, Objective) AND "Baseline start date" is EMPTY AND "Baseline end date" is EMPTY
   2. If FixVersion is EMPTY
   3. Then EDIT issue: 
      1. Baseline start date: {{issue.fixVersion.startDate}}
      2. Baseline end date: {{issue.fixVersion.releaseDate}}

I've also tried it these ways, without success. What am I doing wrong? 

[Isabella Musial]

thank you for helping me! The new Automation Rule works like a charm!

[Bill Sheboy]

Hi @Isabella Musial 

First thing, your rule shows a condition on Fix Version is empty, and then the edit issue actions are referencing that same field (which is empty).  Am I missing the intent of your rule?  Or did you instead want to use a different source value / issue for the edit action?

Can your issues ever have more than one Fix Version?  If so, how do you want to decide which version (and dates) to use?

Next, one of your rules shown is branching to other issues, but you describe editing the trigger issue.  What is the purpose of the branch?

Finally, when a rule does not work as one expects, reviewing the audit log details showing the rule execution may help.  Would you please pick the rule you want to use and show the audit log details from when you tried executing the rule?

Kind regards,
Bill

[Isabella Musial]

I was hoping to hear from you! LoL 

1. What I am trying to do is the first time we add a FixVersion to the Issue, the rule runs automatically. 
2. We can have multiple fixversions. I only want to update baseline dates based on the first time a FixVersion is added.
3. I was testing if Branching would solve my issue. I think I guessed wrong! 
4. The audit log shows success then I get an emailed failure, but it has not been telling me exactly why it is failing. 

This is the associated Automation Rule

[Isabella Musial]

We have a rule that works which sets the target dates so Sprint start / end on Stories when they are moved into a Sprint. I tried to do the same thing but failed miserably! 

I am not sure what the baseline start date and baseline end date formatting would be to be honest so that those fields would be updated.  These were my best guesses: 

{{issue.fixVersion.releaseDate}}
{{issue.fixVersion.startDate}}

{{issue.customfield_16819}}
{{issue.customfield_16818}}

{{issue.customfield_16819.get(issue.fixVersion.startDate)}}
{{issue.customfield_16818.get(issue.fixVersion.releaseDate)}}

[Bill Sheboy]

Thank you for clarifying the scenario, Isabella.

As you only want the dates set when the first Fix Version is added, I believe the rule can take advantage that Fix Version is a list field.  And so an advanced compare condition may be used to confirm there is only one value by checking the size (count of items):

• first value: {{issue.fixVersions.size|0}}
• condition: equals
• second value: 1

Regarding the dates and automation rules, it may help to look at the smart values and data using this how-to article for finding smart values.  It will show the correct date format.

The essential steps are:

• identify an issue which has your field(s)
• call a REST API function with a browser to search for your issue:

https://<yourinstanceurl>/rest/api/2/issue/<issuekey>?expand=names

• search on the page for your field, such as with CTRL-F
  • if you find the field, you will see the date format to use
  • if you do not find the field, it is not supported by automation rules

https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

[Isabella Musial]

Thank you so much!

I did find the following fields: 

"customfield_16819": "Baseline end date"
"customfield_16818": "Baseline start date"

customfield_10104": "Target end"
customfield_10103": "Target start"

fixVersions": "Fix Version/s"

However, on Jira smart values - issues | Cloud automation Cloud | Atlassian Support, there is a section for {{issue.fixVersions}}. I was hoping I could use issue.fixVersion.ReleaseDate

The dates are populated for each Release, so was hoping that data was available to pull. 

[Bill Sheboy]

Unfortunately, there are lots of typos in the documentation for automation rules and smart values: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/#--issue.fixVersions--

Assuming there is only one version in the issue, you may get the release date from it with this:

{{issue.fixVersions.releaseDate}}

And then adjust the format to what is needed for the other fields.  The most likely one for those fields is jiraDate, and so that would be this:

{{issue.fixVersions.releaseDate.jiraDate}}

[Isabella Musial]

What about using 

[Bill Sheboy]

That trigger fires when some fields of a version are updated.  That is independent of any issues being linked to the version (such as with Fix Version or Affected Version).  Note that not all changes to a version will trigger that one.

It seems your scenario has changed a bit.  Under what conditions do you want the rule to do what?  Knowing that will help to adjust the trigger and perhaps the actions.  Perhaps try describing that as "what problem you are trying to solve" to focus the scenario.  Thanks!

[Isabella Musial]

Conditions: 

If the fixversion field is empty and a user adds the fixVersion for the first time, then: 

1. The Baseline start date is updated to match the FixVersion Start Date
2. The Baseline end date is updated to match the FixVersion Release Date

I have another scenario that I am looking to get together, but one Automation Rule at a time. 

[Bill Sheboy]

Thanks, and you were on the right path initially:

• trigger: issue field updated for fix version
• advanced compare condition: to check if the field was empty with the change log
• advanced compare condition: to check if there is one-and-only-one version in the field
• action: edit issue, to set the fields from the fix version

I believe we have covered all those pieces.  Please try that to see how it works.

[Isabella Musial]

Thank you.... it worked for EPICS! WooHoo! 

But - we also want it on Capabilities, Milestones and Initiatives. When I updated the Rule to contain these 3 new issue types, the Rule says that the issues did not match the condition. All three issues have the FixVersion field and the baseline fields available. 

See attached Rule & Audit Log

[Bill Sheboy]

The way your condition is written, it will not update for those issue types.

Do you want to invert that first condition, so it only updates if the issue type is Epic, Capability, Milestone, or PI Objective?

[Isabella Musial]

Yes... type is Epic, Capability, Milestone, or Initiative. No longer need Objective.

[Bill Sheboy]

Great; please change that condition from "issue type is not one of" to "issue type is one of" and re-test.

[Isabella Musial]

That was it!!!!! Stupid me! 

That works all around!!!!! Thanks so much! 

Now - I need to create a manual Automation Rule that I can hit that will update the baseline dates to match target dates. You may be seeing another question coming your way! 

[Bill Sheboy]

Do you want to close this one out as "answered" to create another, or do you see it as part of the original question?