nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Fields hidden from the Edit screen can now be edited via API (and Rovo). Please vote for JRACLOUD-98

Vanessa Mouriz

Hi team!!

I'd like to draw your attention to a bug that I think deserves much more visibility than it currently has: JRACLOUD-98054, "Want a way to restrict editing issue field value through REST API".

What changed

Until recently, if a field wasn't on the Edit screen, it couldn't be edited either in the UI or through the REST API. After the deprecation of override screen security and the project/field association changes for company-managed projects, that's no longer true. A field that isn't on the Edit screen still can't be edited in the UI, but it can be edited through the API.

Why this matters more than it seems

Jira Cloud has no native field-level permissions. For many of us, keeping a field off the Edit screen was the practical way to protect values that should only change through a workflow transition, an automation rule, or an integration. Typical examples are approval fields, SLA-related data, financial or contractual values, and fields synced with external systems.

Exploiting this used to require API knowledge, so the real-world risk was limited. With Rovo, that barrier is gone. I've tested it: any user can ask Rovo in plain language to update a field that isn't on the Edit screen, and the change goes through. What used to be a technical edge case is now available to every licensed user, with no technical skills needed.

Current status

The ticket is in Gathering Impact with Low priority, which doesn't reflect the impact this has on governance and data integrity.

How you can help

Vote for JRACLOUD-98054.
Leave a comment with your use case: which fields you were protecting this way, and what breaks for you now. Concrete examples are what helps Atlassian measure the impact.
If this affects your customers or your organisation, raise a support ticket and link it to the bug.

Has anyone found a reliable workaround in the meantime, such as automation rules that revert changes or alerts on field updates? I'd love to hear how others are handling it.

Thanks!

Comments

Julia Foden

Hi Vanessa

Thank you for this post and the information. I have often relied on leaving certain fields off the edit screen which are only filled by workflow post-functions or automation. As you said, these would be fields related to approvals and peer review etc on processes subject to audit. In these cases it is essential that the Jira data is an accurate representation of who did what when, and auditors need to have confidence that the Jira data is tamper-proof. (As I recall though, fields not on the edit screen can be edited via Bulk change, but then that be restricted via the global permission.)

So I am horrified to read that Rovo enables users to edit non-editable fields 😮

Nathan Panuco

I've confirmed reporduction in my work environment too. I'm extremely surprised. I would have expected it to operate the same way the MCP does - in my personal environment if it's not on the edit screen or on a transition screen Claude cannot edit the field.

It is possible to block some of the fields from being edited directly using a Property on the workflow. I've used this to stop folks from changing the assignee on some work types and only allowing for changes, but I haven't tested this 'bug' on that yet. I do know the Property will prevent automation rules from altering it so I assume it will work in this case too.

The following is from brainstorming session with Rovo:

As a partial workaround, you can enforce field/action restrictions at the workflow status level using Workflow Status Properties.

How It Works & Key Limitation

Jira does not support arbitrary field-level properties (there is no jira.field.<customField>.editable = false). Workflow properties override Jira’s underlying Permission Scheme keys per status.

As a result, you can only selectively lock fields and actions that have dedicated, independent permission keys:

Field / Action	Property Key (Value: leave empty)	What It Blocks
Assignee	`jira.permission.assign.denied`	Prevents changing the Assignee
Reporter	`jira.permission.modifyreporter.denied`	Prevents changing the Reporter
Due Date	`jira.permission.scheduleissue.denied`	Prevents modifying the Due Date
Security Level	`jira.permission.setsecurity.denied`	Prevents changing Issue Security
Worklogs	`jira.permission.work.denied`	Prevents logging/editing work
Attachments	`jira.permission.attach.denied`	Prevents adding/modifying attachments
Comments	`jira.permission.comment.denied`	Prevents adding new comments
Issue Links	`jira.permission.link.denied`	Prevents linking issues
All Fields (Full Lock)	`jira.issue.editable = false`	Locks the entire ticket from edits

Note on Custom & Other Standard Fields: Fields like Summary, Description, Priority, and all custom fields are bundled under the general Edit Issues (edit) permission. They cannot be locked individually without locking the entire issue (jira.issue.editable = false or jira.permission.edit.denied).

How to Configure:

Navigate to Project / Space Settings > Workflows and Edit your workflow (diagram view).
Select the specific Status (not transition) you want to protect.
In the side panel, click Properties > Add Property.
Enter the Property Key (e.g., jira.permission.assign.denied), leave the Property Value blank, and click Save.
Publish the updated workflow.

For the full list of supported permission keys and syntax (including how to restrict permissions to specific project roles or groups), refer to the official https://support.atlassian.com/jira-cloud-administration/docs/use-workflow-properties/ .

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

jira-administration

bug