Extract previous (latest) assignee from a ticket using smart value

[Vandyck Lai Kai Yong]

Hi, I am figuring out how to retrieve the previous assignee from a ticket request.

The reason why I am doing this is to remove the assignee from the watcher list once that particular person is being moved out of the assignee. I am thinking of smart value implementing on an automation.

This is the automation that I have in mind but it does not work due to the invalid smart value.

[Bill Sheboy · Accepted solution]

Hi @Vandyck Lai Kai Yong 

Have you tried using the change log to access this value?  For example, this would return the ID of the previous assignee, assuming you have the same trigger of field change on assignee:

{{changelog.assignee.from}}

Best regards,

Bill

[Vandyck Lai Kai Yong]

Hey @Bill Sheboy 

This works perfectly, thank you so much.

[Janusz Bułakowski]

Hey @Bill Sheboy any idea how to change this id into displayName :) because 
{{changelog.assignee.from.displayName}} is not working.

[Bill Sheboy]

Hi @Janusz Bułakowski 

I believe you can only get the account id value from the change log for users, and so there are a couple of work-arounds to get the displayName:

1. set that value to a user field (either an existing one or a custom field), re-fetch the issue, and then you can access the displayName from the updated field
2. call the REST API from the rule with a web request action using the account id to get the other user fields.

Kind regards,
Bill

[Janusz Bułakowski]

thank You

[Derek Owens]

Thanks again, Bill. You have helped me so many times through others' questions.

[mario.lurig]

Slightly different answer to a similar question.

We wanted to get the previous assignee before automation changed it (as part of a workflow transition post action) to assignee "Automation by Jira" so we could set it back to the original. Here's the important details:

Create Variable {{oldAssigneeId}} with the smart value {{assignee.accountId}}
Edit Field (Assignee): {{oldAssigneeId}}

TL;DR To store and use assignee, you need to be using the unique Account ID of that user, and that is stored in the {{assignee.accountId}} smart value. Reference: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-users/

[Joe Harrington]

Hi @mario.lurig , I'm looking to revert an assignee to a previous assignee (could be one of several, not a constant value) upon the transition of an issue from one status to one of two statuses. Do you know if there's a way to change the smart value {{assignee.acountId}} to be dynamic and point to an assignee at a certain status in the workflow?

-Thanks,

Joe

[mario.lurig]

Not that I'm aware of. There is the audit log, but I wasn't able to access the smartvalues from there well. 

[Bill Sheboy]

Hi @Joe Harrington 

There isn't anything built-in to do that. 

If you are always going back to the prior assignee, you could save the prior assignee whenever it changes, in a custom field and use that value later to revert.  If your workflow allows multiple transitions, and you want to target one prior status (e.g. back to the person assigned when in "Build") you could save multiple values in multiple custom fields.

Kind regards,
Bill

[Joe Harrington]

Hi Bill,

We do allow multiple transitions, but the primary use case I was targeting was when an issue is being tested in QA and the status/column in Under Testing, when the QA tester moves it either to Done or to Rejected, then the original dev (most likely the one assigned when the issue was automatically transitioned from In Progress to Code Review via our integration with Azure DevOps and the related PR is created) would be automatically assigned.

Could you please elaborate on how to implement the custom field workaround for targeting prior assignees at a point in time? Would I just create a custom field "Original Dev" and save the assignee when the issue transitions automatically from In Progress to Ready for Testing, and then when the issue transitions from Under Testing to Rejected or Done then the Original Dev assignee is assigned?

[Bill Sheboy]

Yes, you have explained it well: save the assignee you want to return to (when in the development status), and use that later to re-assign, as needed.

For example to do this as you describe, first work with your admin to create the "Original Dev" custom field as a single, user field.  Then in your rule...

• trigger: transition to "Ready for Testing"
• action: edit issue to set "Original Dev" to Assignee

Later, use that custom field to re-assign in another rule.

[Gabriel]

FYI, this is now available.

Use the Assign issue action, select Another field value or comment, and then select Previous assignee:

[Marco Brundel]

Hi @Vandyck Lai Kai Yong 

In another community item ( https://community.atlassian.com/t5/Marketplace-Apps-Integrations/How-can-assign-previous-user-on-a-defined-issue-status/qaq-p/650912 ) 

I see Andreas mentioning the following smart value. 

{{issue.Previous Assignee}}

Does this work for you?

Regards. Marco

[Vandyck Lai Kai Yong]

Hi @Marco Brundel 

It does not work but I came up with an idea is there any way for me to extract the assignee value from audit log in another automation and remove the watcher by running the "Remove assignee from watcher" automation?

Something like this, I want to retrieve the assignee value from this audit log to be used in the remove watcher block.

Cheers,

Lai Kai Yong

[rajeswari saravanan]

Hi @Vandyck Lai Kai Yong 

I have similar task to get the value of assignee in one of the status

eg-

we do have

code review —> ready for test —> In test —> testing complete —>dod review 

In this,when we are moving to DoD review ,I want the assignee whom its been assigned in code review status using smart values (automation rule) please guide us in this.

@Derek Owens @Bill Sheboy @Rinaldi James Michael 

Any help much appreciated :)

[Bill Sheboy]

Hi @rajeswari saravanan 

As this is an older thread, I recommend creating a new question, and perhaps linking to this one.  That will ensure the maximum number of people see it to offer suggestions.

When you create your question, please include:

• explain the problem you are trying to solve; that is, "why do this"
• include an image of your complete rule
• include images of any relevant trigger, actions, conditions, and branches
• include an image of the audit log details showing the rule execution
• explain what is not working as expected and how you know that

Thanks!

Kind regards,
Bill

[Rinaldi James Michael]

This works for me in Jira Data Center. None of the other answers worked for me. Maybe these only work for a while.

{{changelog.assignee.fromString}}

[Bill Sheboy]

Hi @Rinaldi James Michael 

Context is important for rules, and so perhaps your rule structure (and use of the changelog) prevented the other methods from helping.

{{from}} returns the entire object (i.e., assignee) and {{fromString}} returns whatever the default attribute is.  That is different for different objects, and could be id, name, value, or the entire field.  And so your rule structure may have only been helped using that default attribute, which I believe is the accountId for the assignee field.

Kind regards,
Bill