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

JIRA Is it possible to hide fields from certain users?

Rick Apicella

My company uses JIRA as a support service and we want to prioritize tickets in the most efficient way. The priority field seems like a great idea but then clients can see what we have labeled their ticket. Just wanted to see if you could hide that field from a group of users or make it accessible to only a certain group.

For ex: support-group which as complete access to the project Support and see's all fields in support tickets. external-client-group permission does not allow it to see priority field.

Accepted answers

Nic Brough -Adaptavist-

Jira doesn't do field level security. See https://jira.atlassian.com/browse/JRA-1330 for discussion and work-arounds.

There is a "field security" plugin from quisapps, which enables a lot of functions you'd expect from this, but you can't install it in OnDemand.

All comments

Nic Brough -Adaptavist-

Jira doesn't do field level security. See https://jira.atlassian.com/browse/JRA-1330 for discussion and work-arounds.

There is a "field security" plugin from quisapps, which enables a lot of functions you'd expect from this, but you can't install it in OnDemand.

Rick Apicella

Thank you for this.

Sukanta Datta

Also you can create screen what customer can see and eliminate priority field from their view.

Nic Brough -Adaptavist-

Not without hiding it from everyone.

Sukanta Datta

So are you saying I can't create a seperate view screen for each group of users

Nic Brough -Adaptavist-

Correct.

An issue has data. You can show it, or you can hide it completely.

There is no way to hide it selectively below an issue level (You can hide projects, and you can hide issues, but not fields)

There is the Quisapps "field security" plugin - that does most of what I'd want from "field security".

Natalie Hobson

I know this isn't what you asked for, and it's kind of sneaky, but...what if you created a custom field, gave it and it's options names that the client doesn't recognize (or wouldn't pay attention to), and have that act as a replacement for Priority? So, maybe something like "Work Team", and give it options "A", "B", "C", "D", "E", and your developers know that "A" means the same as "Blocker", "B" the same as "Critical", etc.? I know this sounds kind of silly, but if the main problem is wanting to make sure clients don't know what the priority of their issue is, this might work...

Rick Apicella

Ah ok. Thank you for this.

Chrisjir Parkin

How about this.

Add the field to transition screens that the customer doesn't see (because Conditions on the transition permit only people in a certain role, say, "internal group" to make that transition). On the transition screen, a member of Internal Group is shown the field and can set its value. You can even add transitions that connect from a status back to itself purely for the purpose of updating fields that are not visible to, or editable by, people outside a particular role.

We use this technique to edit Resolution. Generally, we want the Resolution field to be set as a post function on transitions that close issues. But, sometimes people choose the wrong transition when they close a ticket, and the Resolution is wrong as a result. In those cases, we empower a specific project Role called, for example, Project Editors to make a transition that edits the Resolution field. The transition starts and ends on the same Status (Closed), and has conditions that let only Project Editors use it, so it only appears as a button for that group.

You could create fields that are hidden from the Customer but visible to people who can make special transitions. You can still use these hidden fields in JQL to identify tickets to act on. For example, you might not want people to see, or to change, a field with a drop-down choice of yes/no that is named "Budget Approval", but you definitely want to see all the tickets that have the value "No" or value null.

I imagine that this will not prevent users from writing JQL of their own, if they find out the field name, so the only remaining question is whether the field value would display in a filter column, even if it were not visible in the Issue itself. Have to test that.

Tim Nixon_qtekck

Yes, if you add the column name to the JQL results it will show up on the results page.

So the only true way to hide data is to hide the issue itself using "Security Level" which really does not accomplish what several of us would like to accomplish: to be able to completely restrict access on a field (e.g. hidden from all screens including view and also JQL results) perhaps based on user or users group affiliation/project role etc.

Basically field level access rights I guess it might be called.. read/write, read only, None

Nic Brough -Adaptavist-

This doesn't hide the fields from people at all. It just protects editing a bit.

Peter Blom

Ah how unfortunate is this... Moved everything from Server to Cloud for obvious reasons. But now we are not able to hide fields from our clients. We use specific fields for additional notes. Also we have fields related to costs like this: One 'EDIT COSTS FIELD' that normally we only see... And one 'COSTS' field that is populated through automation and then only visible to the client.

Anyone with a solution yet on the JIRA Cloud setup?

Nic Brough -Adaptavist-

You can't hide fields from users on Server either, not without an app.

I assume you were using something like the Quisapps field security app. There are no equivalents for Cloud, the framework does not support it (we're not sure that it ever will!)

Peter Blom

This is a real challenge... 😥. Not only do we have the issue with the costs fields. Also with the time logged fields. How frustrating after 40 hours of work configuring the Cloud instances 😅. Back to the drawingboard for us to see if we need to move to a completely new configuration now that we still can.

Still so many people ask for user-rights managed fields in the responses I see everywhere. Sound completely logical to me as well.

Ulrich Althaus

Hi Peter,

were you able to solve this problem? We have the very same need to hide information for some users. Currently we use Quisapps field security. We are planning to move to the cloud.

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-cloud