Need this too. I have to hand-type a Confluence page list of every one of our Jira Issues (just the names of the issues, nothing else) for our internal customers to see because they're not allowed to see anything else and there's no way for me to set a view that only allows people outside our team to see just the issue names.
 

@Jira, if you had done this, you would have gained lots of recruitment tool seekers as customers... 

So @takeafumi your claim above about making an app to solve this problem isn't really that accurate.  Sadly Jira is NEVER doing this. Hopefully one day someone does, but I'm confident that plugin will be insanely expensive.

Ok thank you

Thank you for asking.

Hello Nick,
The app supports only custom fields. You have to create new custom fields from a custom field type the app provides to enable field-level permission.
So, unfortunately, you can’t hide system fields and Jira standard custom fields.

Hello, Lillian,
It's for free now. However, it will be paid app after the beta period. We haven't determined when it will be and how much it will be.
P.S. I think I replied to your support ticket on Oct. 4. I'm sorry if you didn't get the reply.

@takeafumi - I created a ticket asking if we try it remains free or you start charging after a period of time? I didn't hear back. Don't want to start using then get charged alter - I need approval prior to any new purchases.

Takafumi does this actually work for hiding Jira fields or just custom ones?  It does not mention time tracking or any other Jira fields in the listing.

Disclaimer: I’m a developer of the app.

I developed an app Secure Custom Fields for Jira to resolve this problem for Jira Cloud.

Link: https://marketplace.atlassian.com/apps/1226365/secure-custom-fields-for-jira?hosting=cloud&tab=overview

It's a free app now.
Please try it if you don't mind.

@Roy  a solution that would work for this would be to put security into the tab view and then special tabs could be created and fields placed into those for "hiding" certain fields from view.  

@Scott McKibbin. If this is for editing fields, an automation may work.

https://getsupport.atlassian.com/browse/JST-620376

Looking for any work around available for Jira Cloud. The only thing I can think of is using a separate project and using automation to sync the issues, keeping the sensitive data in an internal project and the client facing data in a service desk or separate software project.

Try Field Hide for JIRA plugin and give us feedback. It hides fields based on group/role/user and even project and issue type.

Link: https://marketplace.atlassian.com/apps/1221774/field-hide-for-jira?hosting=server&tab=overview

We keep adding new features in the future

The third party plugin is good at the basics, but cannot deliver the full functionality that I would expect fully hidden fields to deliver. It "leaks", allowing users to see fields (and in some cases, allows them to see and edit data) that are not supposed to be able see or edit.

This is not a weakness in the plugin, it's because Jira's field architecture does not support a full hide. That's what Atlassian have said they are not going to rewrite.

 Third Party plugins is released this functional. But Atlassian said about revelop jira. Facepalm

Understand this is closed but as a workaround is there a way you can hide a tab so I can put my fields in there and use security on who can see that tab? 

I want to add +1 as Jira user - we need this feature.

I need this field level security for Escalation & Approval use-cases, either field level security or VIEW & EDIT page should have different screen, so this can be controlled using workflow.

Keep Secure fields on VIEW page but not on EDIT or CREATE, create a transition with screen having secure fields and grant access on transition to usergroup need access on that particular secure field.

----------------------------------

So we need :-

Either 1. field level security OR 2. EDIT & VIEW page should be different to achieve same.

Regards, Anil

The products are not complaint with Federal Standards (IRS 1075, NIST 800-53..) which means your competitors will always have the advantage. This is why I have not seen your products on the GSA schedule.  Recommend employing qualified information security staff that can articulate the value of  industry standards. 

Shane, I highly encourage you to forget JIRA for open source. GitHub is where open source happens, you loose on tons of visibility (to begin with, and tons of other advantages too) with using JIRA. Not to mention JIRA's UI is still like a jet's cockpit compared to the GitHub issue tracker (and it's one thing having your trained team members know their way around, and it's another thing asking everybody else to also use it for their valuable feedback about your project).

This is what we also do: JIRA for internal issues, for open source GitHub all the way.

We are developing an open-source project (International Components for Unicode), and our Jira Cloud instance is publicly viewable.  However, when filing a ticket as a guest, sometimes users can submit personally identifiable information such as their email address.  We would like to make the email address field protected from public view while still having it in the database for team members to use.

Your decision is unacceptable when regulatory compliance is required.  It seems you will not be used and we are looking at a competitor. Government organizations are bound to comply with standards and compliance with the ability for non-repudiation at the field level. 

Wow, more than FIFTEEN years later and still no desire to give clients what they pay for. It should be possible to consider the pre-requisites of this requirement in a core renovation you normally do every couple of years. Or did Atlassian skip these in favor of implementing more "visible" new features?

Compare this with Open Source projects like Mantis where you have the option to implement such a missing feature for yourself and - if you are inclined to do so - give it back to the community.

I'm actually really really irritated by this decision for two reasons:

1) Obviously there is a viable solution since there's a plugin.

2) This viable solution ISN'T available on JIRA Cloud in any form for some reason. The only thing I found was on JFS forum saying that it wasn't possible:

https://quisapps.com/node/4056

This seems to be true since I can't find ANY plugin that does remotely the thing that I need. Is there any solution that doesn't involve an incredibly convoluted workflow / screen setup that will give field level security in JIRA Cloud?

Very annoying decision. We have users messing around with Fixed Date, forcing project managers to take screen caps of the Fixed Date fields every weekend so they'll which tickets were changed.

I appreciate that the issue is closed therefore so is the voting, but comments/dialogue or a new issue is the only obvious mechanism to capture feedback (but it doesn't capture voting trends and therefore appetite post closure). Anyway, it is what it is!

Field level security would certainly be incredibly useful in our JIRA implementation and would save having to install/maintain/finance 'yet another plugin'.

Yes kel1271744356, Feature requests are often revised as they may become more relevant with the introduction of other features and with the different additions that come with time. We encourage all our customers to give their feedback even if the feature request is currently closed, as new arguments and detailed use cases could bring them back to the table for consideration.

It can, but Atlassian still have no intention of doing this.

Can a decision made 10 years ago be revisited?

none of the Workaround links in Description work. Can you please update the links? Thanks.

@Shlomi Hazan, I'd suggest reading further back through the conversation for all the reasons it's not going to be done, and the options for implementing something to help out (Also note that "it's been 13 years" is not any reason to do something)

@Joe Ferarra 

This issue was raised 13 years ago, I think it is enough time to find a solution don't you think

@Shlomi Hazan

That plugin may have taken a long time to develop.

@Giacomo Kavanagh

That's absolutely correct, they feel that the time spent to develop it doesn't justify the "payout" and thus are making an intelligent business decision.

They can do it, they just don't want to.

I'm still hopping that you will reconsider.

How come you can't do it but you point us to a plug-in that can handle it?

Thats the GREAT pity. Albo pitu pitu

I'm watching this issue since 5 years

What a pity !

Jack, it is "done", if you look at the status. Atlassian are not going to implement it.

Hi,

Could you let me know when this is done please?

Thanks,
Jack

The inability to restrict field permissions in Jira Cloud creates a huge SOX compliance gap for us. We've implemented the workaround where Edit is disabled and replaced with an interstitial workflow screen, but that solution is so hackish.

+1

This really is a necessary feature to our team. We should be able to prevent prevent a group of users or project role from editing default or customized issue fields via workflow.

Removing comment - generally unhappy with Jira

Hate to pile on, but I'm going to... This really is a necessary feature. In your original status comment, you mention implementation would make Jira administration more difficult. I submit it is not having this feature that make using Jira difficult.

Really need this Field level security for our Jira on Cloud. Most of the AdOns do not apply to Jira on cloud.

So please help or provide some ad on.

Hi, I'm using Jira 6.3.13. Is there a way to limit a custom field to be viewed by certain groups/users, the same way the Comment field is?

+1

+1

We need field level permissions too on our cloud instance

+1

+1

"We have reviewed this request again within the team and have had long conversations with our JIRA architect. This has lead to the conclusion that the original reasons for not implementing this feature still apply."

Roy Krishna
JIRA Product Management

Based on what you're saying you made a purposeful decision to not implement this feature when you originally designed the platform and you still feel that this original vision is a valid approach. I'd be interested in understanding why as it would help me make a more informed decision about how we use Atlassian products in the future. Am I to understand that Jira will never ship with built in field level permission or even more specific the ability to turn off all time tracking / worklog features for a specific role?

thx

+1

+1, this is something we could use as well!

+1

Sorry, I didn't notice "Won't fix" reason - then right.

Why? Because the answer is BS. This is clearly a matter of extreme importance to many people and the door has been slammed in our faces. The hope is that maybe if Atlassian decides to listen to us one day they may reconsider their position on this issue before we reconsider our positions on license renewal.

Why you people make mess by adding this +1 meaningless comments? Why not using "vote for this issue" button?

+1

+1

There's no way to do it on Cloud at all - even if you could hide fields with javascript in the issue view (and I don't think you can on Cloud) the information is still in the html, still available over REST and will still show in searches and lots of other places.

Hi Daniel,
We have implemented cloud verison JIRA and I am looking for same field level security (basically to hide a cost field from vendor team) - can you please tell me if you found any cloud plug in to implement?

+1

The JIRA web interface isn't the only way a user can interact with JIRA tickets.

Chris - I don't think it's simplistic for this request. I am attempting the same exact thing and...if I could simply configure the fields on the create screen and associate that screen in the Screen Scheme based upon user groups (in this case the Client group) this would in fact solve the objective. And no, they would not be able to enter say 'priority' (or severity level in our case of the customized field) if the field didn't appear on the screen (i.e. if you don't see it you can't enter it). Not sure what you mean by 'the API' in this context. I simply want a way to specify different screens (that I have created) with different fields for Create, Edit, View in the Screen Scheme by group. It's done exactly that way now, except you can only specify one Create, one Edit, and one View screen (configured with whatever fields you'd like) to be associated with every user in a Screen Scheme - and as stated - if you don't include a field on one of those screen you can't enter data into it. So in essence - if you can't see it, you can't edit it. Works that way now - all I'm asking is to expand what's already there.

Perhaps you haven't created different screens for Create, Edit, View and associated screen schemes.

This solution would simply allow you to specify multiple screen

I think it is a little bit simplistic to say that "if you can't see it, you can't edit it"... there are other things to consider, eg. the api. I agree with the sentiment though... work with your customers to give them what they want.

Ugh...that was supposed to say "and as a_ result _you've abandoned it"

Bottom line - just work together to find a solution that will accommodate the requirement or at least the fundamental business need....don't assume it requires 'field level permissions' or that's the only path you'll go down.

Simplicity is a thing of beauty!

You guys are making this was too complicated and as a realist you've abandoned it. You don't have to create field level permissions - quite honestly nobody enjoys the maintenance of such a solution. The business requirement is that when external customers are given the access and flexibility to create issues within a project in JIRA, the project owners would like to control what they see and what they can enter. If someone can't 'see' a field they in essence do not have permission to enter data into the field....therefore, how about just implementing something like: Group Level Screens within a schema...Client Group sees Create Issue (Client) screen when logging in....Internal Group sees Create Issue (Internal) screen when they log in...same for Edit and View.

This has to be exponentially less complicated (from both a development and configuration / maintenance stand-point) than approaching this from the Field Level Permissions perspective.

+1 ....

+1 (Seriously!!)

+1

+1

+1

+1

+1

+1 Would be awesome

+1 000 000 000

@PeterCselotei: Vote is disabled because issue is closed with "Won't Fix".
As @RachelGrimmelmann wrote, this feature is still highly demanded - also 12 year later addressing it.
We are spending thousand of dollars every year to get this tool improved and maintained. It is worth mentioning to @Atlassian, that we would like to see this feature better sooner then later. @Atlassian had 12 years to think about how to implement this feature request.

+1

vote don't work.
Issue is closed.
+1

I understand the importance, but you should click on vote instead of these +1 comments. Less spam Thanks

Neil, this is an important feature for enterprises, regardless of the impact, it is weird to find third party plugins that provide this feature, while JIRA developers can't...
+1 (again)

I don't think all the +1s in the world will change their mind, they've clearly stated it will not be done and described the effort and impact to the system, If I take them at face value of super complicating the admin and taking 12-18 months to do a ground up rewrite is not feasible for any development team for one feature, would you want your own dev teams to be hijacked like that?

+1

+1

+1

+1

+1

+1

+1

+1

+1

I still support this request...after eight years of using Jira

@Atlassian: From a customer perspective @rachel.grimmelmann is right. I support her request. +1

@Atlassian, if this issue was originally raised twelve years ago and folks are still demanding it today, it is worth looking in to again. Please!

Thank you,
Rachel

Hi fellows,

long time no update for one of the most important JIRA issues.

We switched from Server to Cloud and oops there is no Field Security Plugin anymore. So time tracking and estimations are visible to our clients now. Is there any way to workaround this for JIRA cloud?

@Atlassian - I like the products and the support very mutch but this issue shouldnt be closed. It should stay open until the DEV team finds a suitable solution.

Thx for any fresh idea
daniel

I appreciate the team's transparency and honesty on this matter. Keep up the good work!