How to Restrict Approvals to Certain People or Groups?

[clerambeau]

Hello. I am new to JIRA and need some help. I am way over my head. We have this task. It is being reused because there is some external automation at work which reuses its unique key. It jumps between statuses (To-do, In Progress, Resolved, Failed). But that is not important. What is important is that I need to enforce the following logic,

1) The task should be visible to the developers who upload Oracle database SQL scripts to it as attachments, and the Database admins who review and approve them, move to "In Progress" then automation takes over.

2) The field "Approved by DBA" should only be fillable by the DBAs by entering any of their names, because they need to review the uploaded scripts for errors, so god forbid a production database doesnt gets accidentally deleted by the automation next.

So, how do I restrict the "Approved by DBA" field only to be used by a specific group (like "DBAs") or specific people? The solution is probably super-simple, but I lack the knowledge, I am just an Oracle DBA. But I have admin privileges within this DEV Atlassian account, so I can recreate the task or even the entire project, if needed. May be it shouldn't be a task to begin with, but some other entity (which?)

Here is a screenshot. Many thanks in advance.

[Ajay _view26_]

Hi @clerambeau 

What you're describing involves two separate requirements: Process Control (approving the action) and Data Integrity (restricting field edits). Since Jira Service Management does not offer native field-level restrictions, it is best to separate these concerns.

1. The Native Solution: Using Workflow Approval Gates

Instead of trying to "lock" a field, use JSM’s native approval functionality. This ensures that only authorized users (e.g., your DBAs group) can move a ticket to the next stage

• Edit your workflow and add an Approval step to the relevant transition (e.g., "Ready for DBA Review" to "Approved")

• You can configure the approval to require a response from a specific Jira Group. The system automatically records who approved it and when, creating a permanent audit trail that cannot be tampered with by regular users. This removes the need for a manual "Approved by" field entirely

2. Restricting Field Edits (Workarounds)

If you must have a specific field that only DBAs can edit, you have three primary options in JSM Cloud - 

• Option A: Workflow Properties (The "Status Lock") You can use the jira.permission.edit.group property on a specific workflow status. This allows you to lock the entire issue so that only members of the DBA group can edit it while it is in that status.

• Option B: Automation for Jira Create an automation rule: When Value Changes for [Field] → If User is NOT in Group [DBAs] → Edit Issue (revert to previous value) and add an Internal Comment. This doesn't stop the click, but it prevents the data from being changed by unauthorized users.

• Option C: Third-Party Apps (The "Granular" Way) If true field-level hiding or "read-only" states are mandatory for your UI, you will need an app like ScriptRunner for Jira (Behaviours) or Jira Misc Workflow Extensions (JMWE). These allow you to set fields to read-only based on the user's group or role dynamically.