Jira automation rule to prevent user from modifying a field unless a member of a group

[Steven Rhodes]

I've been trying to figure out how to reset the value of a single select dropdown to its previous value if a user who does not belong in a certain group, changes the field.

So far this involves a field value changed trigger, and then an if block to check if the user is not in this group.

The Edit Issue action I would hope would set the value back to what it was, but I havent got that far yet.

This is for cloud standard, on a classic project.

[Steven Rhodes · Accepted solution]

Took me some days but I created a Field Value Changed trigger on the Severity field (for all operations), added an If Block user condition with the user who triggered the event with a check to see if they were not in the specified group. Then, and and Edit Issue field on the same field, with a smart value rule of 

{{fieldChange.fromString}}

The downside is that if the user can't change the field, they think they have but next time the screen is refreshed it will revert to the old value. 

[Mykenna Cepek]

You could also consider notifying the user who attempted the change, to let them know that their attemped change was reverted. An "Email" action would do that.

[Bill Sheboy]

Hi @Steven Rhodes 

Yes, and...to the answer: This seems like an opportunity for a conversation with people changing things when not in the team's group.  What problem were they trying to solve by doing so?  Understanding that may help them and your team.

Best regards,

Bill

[Sadeesh Narendran]

@Steven Rhodes Why do you want others who is not in your group to edit the field. Cant u set the permission to restrict the user from this group to edit the ticket.

[Mykenna Cepek]

My assumption was that most users can edit the ticket (and the specific field in question), whereas there is a group of users who should not be able to edit that one field.

Perhaps @Steven Rhodes can validate this assumption?

Standard Jira Cloud permission schemes do not have field-level granularity.

[Steven Rhodes]

The assumption is that people with access to the project can create and edit issues, but only members of the project team should be able to change the field. 

In this case, it is a "Severity" field. I'm hoping that the smart values here will help me

https://support.atlassian.com/jira-software-cloud/docs/smart-values-general/#Smartvaluesgeneral---eventType--

---

{{fieldChange}}

Available anywhere smart values are supported, to access the value of a field that has changed. For example, if the Assignee of a field changes, you could add a comment to the issue to note who the previous assignee was, and who the new assignee is.

When there are multiple fields that have changed, {{fieldChange}} only contains the first changed value. If multiple values are changed, use # to iterate over these. For example, when setting multiple Fix Versions, then you can iterate over these using {{#changelog.fixVersion}}{{toString}}. Learn more about using smart values with sections and lists.

Available properties

• {fieldChange.fromString}} - Returns the previous value as displayed.
• {fieldChange.toString}} - Returns the new value as displayed.
• {{fieldChange.from}} - Returns the previous raw value, e.g. for a select field. 
• {{fieldChange.to}} Returns the new raw value, e.g. for a select field.

[Mykenna Cepek]

Seems pretty straightforward, but I admit that Jira Automation can be a bit confusing.

Which specific part of this are you stuck on?