Comment on Issue with changed Fix Version from Automation

[David Weir]

I have automation that says:

WHEN an issue transitions to In Progress
IF the issue has a FixVersion of "TBD"
THEN edit the FixVersion to "Next Unreleased Version"

This works great! However, I also want to comment on the issue/send out an email saying that this change took place and in the comment I want it to state the new FixVersion.

This message would work, but it would give me the old FixVersion of "TBD" not the one it would change to:
This issue is automatically being moved to {{issue.fixVersions.name}}

This message doesn't return anything after, "moved to":
This issue is automatically being moved to {{#changelog.fixVersion}}{{toString}}{{/}}

How do I comment on the issue to say:
This issue is automatically being moved to <newFixVersion>

Thank you in advance

[Bill Sheboy · Accepted solution]

Hi @David Weir -- Welcome to the Atlassian Community!

When an automation rule updates an issue, such as assigning the Fix Version, that updates the database only.  It does not update the in-memory data the rule has for the issue.  This is done for both performance reasons and because the rule may need access to the data from the time the rule was triggered.

When you want the issue to reflect the updated data, add the Re-fetch Issue action after your Edit Issue action.

Kind regards,
Bill

[David Weir]

Ah thank you! Can't believe it's that easy. I should've asked sooner.

[David Weir]

Hi again,

I am now trying to include updating the Sprint in my automation. Something like this:
I want it to move to the "Active Sprint"  and am using that in my automation. The automation executes successfully, but the sprint isn't actually changing. How can I get the Sprint to update successfully?

[Bill Sheboy]

Hi, Dave!

Please post an image of your Edit Issue action and of the audit log details showing the rule execution so I can see how the edit is happening.

And...is there a sprint in progress when your rule is running?

[David Weir]

The sprints shown in this log were already manually added from previously completed sprints. I would've expected Sprint 41, which is the current active sprint, to be added. When the Sprint field is completely empty, it stays empty even with this rule.

[Bill Sheboy]

In your write to the audit log, I recommend adding a delimiter / label between the fields to make it clear what is in each field.

If that board has an active sprint when the rule runs, I do not know why the field would not change.

Let's test that hypothesis with some unnecessary rule steps at the end :^)

• action: lookup Issues, with JQL of
  • project = MAYHEM AND sprint IN openSprints() ...add more JQL to match your Mayhem board filter
• action: log
  • issue count in the current, active sprint: {{lookupIssues.size}}

If that count is 0, that is the problem: the rule doesn't detect the active sprint for that board.

[David Weir]

Is there a way to add a new line in the single log?

I've run the JQL query you shared and I do get all of the issues in the current active sprint to display. 

[Bill Sheboy]

No, I believe the audit log strips out all the formatting content.  It can be escaped and converted / displayed in a text editor for easier display.

Back to the symptom: I recommend pausing and examining an example issue updated by the rule and looking at the change history to see what is happening to the Sprint field.

Also, I notice your rule trigger includes transitions to status values such as "Done".  Do you actually want to assign a Done issue to the current / active sprint?

[David Weir]

The issue I posted logs for above, there is nothing recorded in the issue's change history except for the Fix Version change.

For choosing "Active Sprint" does the board matter? The Mayhem Board I am choosing in the Sprint field is just the entire project board, so I figured that would be the best option as it's all-inclusive. We have sub-boards by team, but all boards are using the same Sprint. Does that change anything?

[David Weir]

{{lookupIssues.size}} is returning no value in my audit log. Am I using it correctly? I don't know this smart value.

Audit Log: 
Change Fix Version To: {{issue.fixVersions.name}}
Change Sprint To: {{sprint.name}}
issue count in the current, active sprint: {{lookupIssues.size}}

Returns: 
Change Fix Version To: R14
Change Sprint To: Sprint 41 - <Name>
issue count in the current, active sprint:

Sprint 41 is showing up because it was manually entered in the ticket before the automation ran. The automation in this case only updated the Fix Version. I am also trying re-ordering my automation to edit Sprint first then Fix Version to see if that magically does anything.

[Bill Sheboy]

Backing up a bit: the problem appears to be selecting the incorrect board for the sprint to be assigned in the Edit Issue action.  You have multiple boards, and so multiple sprints.  The correct board must be selected for the assignment to work as expected.

This is validated by the test you did with the Lookup Issues action: if the JQL for that action matches your board filter AND returns no issues, there was no active sprint for that specific board.

[David Weir]

So the multiple boards I have with their filters are:

Mayhem Board: project = Mayhem
Team Board A: project = Mayhem and assignees in (person1, person2, person3)
Team Board B: project = Mayhem and assignees in (person5, person6, person7)

All of those boards are using the same Active Sprint, even the same Sprint ID #

The board I am referencing in my Sprint automation is the Mayhem Board. Since this board has everything that each Team Board has combined, I assumed it should work fine.

I don't want a rule for each Team Board, can I make it work with the board and sprint setup that I have currently?

[Bill Sheboy]

Rather than relying on the Sprint dropdown values in the Edit Issue action, you may need to set the value directly using the sprint ID from a smart value expression by using the REST API endpoints with the Send Web Request to either:

1. get the active sprint(s) for the board and use the ID value found, or...
2. use JQL to gather issues in the current sprint, and then get the active sprint from the first issue found

For Jira Cloud, this would be easier as the Lookup Issues action can return the Sprint field in the result, but that is not the case with Jira Server / Data Center.

[David Weir]

Can this still be done dynamically?

I want the current method because Jira just picks the active sprint. I don't have to do anything other than start and complete sprints. I don't want to have to find and input each sprint ID as I create new sprints.