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; } } }

In JIRA cloud, how to restrict a field only can be changed when the status is change to closed

Benjamin Zhou

In JIRA cloud, how to restrict a field only can be changed by one user and one group when the status is change to closed.

For example, I want to these 2 fields "Number of Users" and "Effort in Hours" only can be changed by one user and one group when the status of this task is "closed"

Screenshot 2026-08-31 154953.png

Thank you in advance for your help.

Accepted answers

All comments

Sebastian Krzewiński

Hi @Benjamin Zhou

I would try to solve this in that way:

fields is RO on view screen
to Closed status there will be a 2 transitions
- 1st one with condition that user and group can see it and with transition screen with fields
- 2nd one with condition to cover all other cases without transition screen (if this transition is necessary)

Regards,

Seba

Benjamin Zhou

@Sebastian Krzewiński thank you for working on my request. Due to I can not change the workflow. Do you have another way?

Gor Greyan

Hi @Benjamin Zhou

Sebastian’s approach is the one I would use as well.

Jira Cloud doesn't have native field-level permissions that make a field editable only for a particular user/group based on status.

A practical solution is to keep these fields read-only during normal work and expose them on a dedicated transition screen when moving to Closed. The transition can then have a condition restricting it to the required user and group.

If everyone else must also be able to close the work item, having a second transition to Closed without those fields, as Sebastian suggested, is a clean way to handle it.

Regards,
Gor

Benjamin Zhou

@Gor Greyan I am sorry my issue is I do not want to change the workflow. I mean I don't want to add one more transition.

Gor Greyan

@Benjamin Zhou

Understood. If you don't want to modify the workflow or add another transition, then native Jira Cloud doesn't provide this capability.

Jira doesn't have field-level permissions that allow you to say: when the status is Closed, only User A or members of Group B can edit these two fields.

If you have ScriptRunner for Jira Cloud, you could look at Behaviours as an alternative. Depending on the field types and screen involved, a Behaviour can make the fields read-only based on conditions such as the current user/group and work item context.

Regards,
Gor

Staffan Redelius

Hi @Benjamin Zhou and welcome

You can restrict the editing permissions for certain groups or persons by adding a workflow property.

It might not be possible to configure as detailed as you describe using custom fields but you could set the property so it is the work item is only editable for a certain group or role when the issue is closed.

Check it out and see if it could be a possible solution to your problem:

https://support.atlassian.com/jira-cloud-administration/docs/use-workflow-properties/

Best regards,
/Staffan

Arkadiusz Wroblewski

Hello @Benjamin Zhou

I would recommend checking this with your administrator, as many of these steps will not be possible without the required permissions.

Best,

Arek🤠

Gabriela - LeanZero

There is a way that adds no transition. The mechanism everyone has reached for attaches to the status itself.

Atlassian's workflow-properties page files jira.permission.* under Status properties, alongside jira.issue.editable: "If you want to enforce restrictions beyond the permission scheme, you can do so with the jira.permission workflow property." You put it on Closed. Nothing self-loops, and nothing new appears in the diagram.

Your one-user-and-one-group shape maps to two keys on that status. jira.permission.edit.group takes a groupId. Use the id, since the group name will silently fail. jira.permission.edit.user takes an accountId. Both are documented with those exact value types, and edit is in the published permission list. If you ever need a second group, the format ends in an optional suffix, which "is an optional number used to add the same property more than once".

It does stop short of your ask. Here is where. It restricts editing on the whole work item in that status, so it covers all fields at once. Every permission in that published list acts at work-item level. The one field-scoped property on the page governs which resolution values appear, which is a different thing entirely. So you get "in Closed, only this person and this group can edit anything", which may be close enough or may not be.

Before you commit: the property only ever takes access away. Your user and group still need Edit work items from the permission scheme first. And the page carries its own warning: "Some of the workflow properties on this page may cause bugs. If something breaks after adding a property, try removing it."

One question decides whether any of this is open to you: is that project company-managed? The properties are edited on the workflow itself, so the answer changes what you can reach.

Arkadiusz Wroblewski

btw which Permissions you have within this space/App ?

Without knowing that, most answers are hallucinating.

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