How can fields be made read-only based on user's project roles?

[Paul Spalitta]

We need to be able to lockdown certain fields based on Project Roles or some other permission scheme. I think with ScriptRunner we can lock down fields during transitions, but there appears to be a hole with the base Edit screen of an issue. I do not see an option to prevent edits on that screen while still displaying the fields read-only. 

[Nic Brough -Adaptavist- · Accepted solution]

Plain Jira does permissions at an issue level, not field.  If you can see an issue, you can see all of it, if you can edit an issue, you can edit all of it.

Roles, permissions, etc, irrelevant.  Everyone has a common interface for the issue, there are a couple of "controlled fields", but that's it.

If you want to restrict by role, you need to use either Scriptrunner Behaviours (powerful, but client-side, so REST actions, and a lot of plugin functions won't be affected, and if someone really wants to bypass it, they can because it's client-side) or apps that provide secured and/or validated fields.

The short answer to this question comes down to "you cannot (natively)" and "even with apps, you are going to struggle".

I would question why you want to do this, as "make fields read only" screams that there is a requirement that is not well-explained enough for us to give you a good answer.

[Paul Spalitta]

@Nic Brough -Adaptavist- I appreciate you taking the time to provide that explanation. There are two categories of fields we want to lockdown.

One, we want to lockdown fields based on permissions. The main examples are the fields that define the risk profile for defects. We are a medical device company and our products have the potential, like many medical device products, of injuring the patient and/or clinicians. We only want the people managing the defect handling process to be able to change the risk profile of an anomaly after it has been created.

Two, we are migrating defect handling from a legacy defect tracking system to Jira. We have fields that are being populated during import which we want to remain untouched for the life of the defect.  Examples of such fields include the legacy defect ID from the old defect management system. And there is at least one field coming from the legacy system that doe not translate well to a native Jira field. So we want to store the legacy data in a read-only custom field. Note: This concept deviates from the initial question but I figured an answer to the permission based question would provide me the tools for this second category.

[Nic Brough -Adaptavist-]

Ok, that's one of the few cases where restricted fields make perfect sense.

The short answer is "Jira does not do it".  It's designed for collaboration and sharing, not hiding, so it does not lend itself to cases where only part of an issue should be visible to different people.

I have only two suggestions here

• Don't use Jira for info that needs partially hiding
• For sensitive data as part of things that need sharing, look to security apps for Jira.  As I mentioned above, most won't cut it (including Behaviours), you need something that hides data at source.  The only things I've seen do this properly are fields I coded for myself (and I'm not 100% sure of those) and the Quisapps field security app.  I really would look at that app

For your external id though - not a problem.  Use a standard field, but do not put it on edit or transition screens, then your users can't edit it, but everyone can see it.

[Paul Spalitta]

There appears to be an add-on available from CoreSoft Labs that will give us the field level controls we need for certain fields called Secure Fields - Data Security & Privacy. It is available here on Atlassian's Marketplace: Secure Fields - Data Security & Privacy.