+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!

Hello Guys,

I find it weird considering that this feature is extremely complex - how come a 3rd party plugin can achieve this functionality whereas Atlassian can't?

Also, can't this be achieved somehow by enhancing the Screen Schemes module?

For instance, I would create:

• Screen A for issue View by Project Role X
• Screen B for issue View by all other project roles
• Screen C for issue Edit by Project Role X
• Screen D for issue Edit by all other project roles
• Screen E for issue Creation by Project Role X
• Screen F for issue Creation by all other project roles

Anyway, hope this will be revisited some day, because obviously it is an essential requirement in any enterprise, especially the large ones.

Best,
Pierre

Jean, entendo seu ponto de vista, mas precisamos dessa melhoria o quanto antes!

Outra coisa, o fornecedor desse plugin é imaturo e irresponsável, não responde e-mail e não libera o aquisição de licença trial para testes durante 30 dias...

Estamos precisando de uma solução definitiva urgente. Por favor, priorize essa questão dentro do time de desenvolvimento da Atlassian.

Grato.

Hello,
Is there finally hope to solve a long awaited feature?
Hiding "time tracking fields" in Jira for external users is a major request for many Jira users.

I see that a new plugin has been made available for the download instance: https://marketplace.atlassian.com/plugins/com.gebsun.plugins.jira.hidetimetracking .

This ability has been requested for more than 10 years ago (check the history of related issues to time tracking). Jira (Atlassian) came up with, for sure, many great features but never solved the real need.

I'm convinced, if this plugin works as described, this would be appreciated by many many Jira users.

Looking forward to the quick responsiveness of Jira Team to make this plugin available in "on demand".

Cheers

The fact that a number of commercial plug-ins exists proves two assertions:

1. This is a useful features that customers of JIRA want
2. It is technically possible to implement it, even though in 2003 and 2007 the architect had reasons to not implement it.

So my opinion is that it's worth having this ticket re-opened and this decision reassessed.

There is more than 1 plugin working around the lack of this functionality.
But none of them works for JIRA OnDemand. So OnDemand customers are once again stuck with no viable solution.

Ranman, Andrew - Atlassian have resolved this as "won't fix".

Ranman - That's why there's no updates, there's no point, it's not going to get done.

Andrew - have a look at Quisapps field security plugin. If that won't work for you, then I'd suggest starting looking for a replacement now. A closed-won't-fix issue is not going to get done (and even if it's re-evaluated, it won't happen in a year or so)

I'm banking on this being properly architected/implemented in JIRA in the next year or so. Failing that, I'm planning on searching for replacements/alternatives.

Any update on this in the past 2 years? It's kind of an important change. I'm hoping your "JIRA Architect" has realized that.

matthias.jupe This is basically just global. But of course you could have either several fields or several groups. Or both.

Hi David, sounds great.
Can I manage this hide fields only global or separately for every own projects?

guys, if anyone is still looking for a solution: we described a pretty low level (i.e. soft-hiding, on the client side) approach to this issue here. Please feel free to look onto this and come back at me in any case of questions.

Disclaimer: this solution requires a small plugin of which we are the developers. Better be honest upfront

This thread is so long and hard-won with deep feelings that I'm very reluctant to add anything BUT one thought I've had for anyone looking to impl JIRA that feels they cannot due to this missing feature would be to create 'shadow issues' (subtasks would be easiest) that have a security level set accordingly such that people who can see the main issue cannot see what's in the shadow issue. You'd need functionality that automates the security level setting, and functionality that automates workflow'ing the 'shadow issue' - items which should not be considered non-trivial - and there are some serious scalability costs to this approach which would need to be noodled over first. However, well, that's the sum total of constructive commentary I believe I have within me to contribute to this issue.
-wc

I've also considered having a listener that resets field values to their previous values if the user is not authorized to change them.

Perhaps this could be implemented in stages, offering a set of securable fields that have a new access model. At least it would be in the core and people could build on these fundamentally secure fields. Later on other fields could potentially be migrated into the securable field system.

We've also recently come up with another work-around that involves auditing field changes instead of preventing them. Using the groovy runner we add a script field that returns the user that last edited the field. Here's some sample code if others are interested.

		def changeHistoryManager = com.atlassian.jira.component.ComponentAccessor.changeHistoryManager;
		def userManager = com.atlassian.jira.component.ComponentAccessor.userManager;

		def updateTime = issue.getCreated();
		def updaterKey = null

		def changeHistories = changeHistoryManager.getAllChangeItems(issue);
		for (changeHistory in changeHistories)
		{
			if (changeHistory.created.after(updateTime) && changeHistory.field == fieldName)
			{
				updaterKey = changeHistory.userKey;
				updateTime = changeHistory.created;
			}
		}
                
		// If there were no changes to the field, check if the field was set when the issue was created.
		if (updaterKey == null)
		{
			def customFieldManager = com.atlassian.jira.component.ComponentAccessor.customFieldManager;
			def field = customFieldManager.getCustomFieldObjectByName(fieldName)
			def value = issue.getCustomFieldValue(field)
			if (value != null)
			{
				updaterKey = issue.reporterId; //key
			}
		}

		return userManager.getUserByNameEvenWhenUnknown(updaterKey);

This is an absolute MUST HAVE feature for ANY issue tracking tool that claims to support workflow. Workflows support process, by restricting various transitions. Workflow should also support various field level restrictions. Some example: only the Assignee can change field x. Only the QA Team can edit various QA fields. Field y can only be changed in states a, b, and c.

When this feature is finally implemented, please make these restrictions transparent. Developers/Users should be able to quickly see what actions are available to them and what actions they are restricted from. For example, an uneditable field on the "View Issue" screen should be disabled/greyed out. Help should be easily available to help users understand WHY the action is unavailable. A tooltip, or nearby help icon, should explain, "The 'X' field is only editable by the QA team.".

The edit vs. view screen workaround is hard to administer, and is confusing to users. Relying on a third-party plugin to add what is essentially core functionality for an issue tracker seems like a very risky move, both for JIRA upgrades and for integration with other plugins. JIRA itself has created custom "read only fields", like the "Imported Bugzilla ID" field. We could create a duplicate read/write permissions-enabled field for every custom field type, but then we run the risk of incompatibilities/out of sync errors whenever the real underlying field changes. Additionally, system level fields remain out of reach for protecting.

I understand this is probably only necessary for "larger companies" with more involved processes, etc. But it seems like this is where you would get most of your revenue. And it seems like a very effective ad campaign to say that we support large company x, y, and z, as well as having those company members continue to use/spread your tools to other companies, small start-ups, etc. Why disqualify yourself early? Please give this feature another shot. Regards, Andrew.

You may want to watch the Live Fields features of JJupin that among others enables you to hide fields depending on any logic (custom field value, status, complex algorithms - like permissions computation for specific users, groups or roles, etc). See examples on Supported fields page or Recipe on hiding Time tracking Information.

If you have specific requirements we may be able to provide you a more targeted solution or hint.

HTH

Although this was a feature requested for some projects (one I hoping could be implemented for our internal clients), I fully appreciate the reasons for not implementing it, and really appreciate the honest and straight forward response. ANd with all the great features seen in the recent releases of JIRA I must agree it was the right decision.

Cheers!

@guis:
I think it's better to ask this on http://answers.atlassian.com

Hello,

How to create a non-editable fields?

Guillaume

Alex

yes you are right about second point. I checked again and timetracking column are visible but empty - its ok.

I have edited my previous comment.

Radoslaw,

We know about the issue with queries and are working to fix that in the next major release. As for Excel, this view is handled by JFS and the user can not view any time tracking data in Excel export if he does not have a permission. If you have any troubles with that view please e-mail me directly and we'll try to resolve it.

Alex
http://quisapps.com

Quisapps Field Security Plugin DOESN'T work properly because:

• each user can use timetracking fields on advanced queries in Jira
• each user can export to xls all fields - including timetracking fields (Menu Issues/Views/Excel) - EDIT 2012.05.04 - xls view works properly. My mistake.

So it is NOT a good solution.

@Brett Ryan - regardless as to your companies policies the pricing structure around JIRA and 3rd party plugins are orders of magnitude below the cost of All other Issue Tracking solutions in the marketplace today. If you compare JIRA with ClearQuest the maintenance fees alone would cover the entire Atlassian suite, let alone the costs involved with supporting that monster.

I understand that every Company's financial situation is different but typically when I give people a chart showing how much time their employees waste w/o the presence of a plugin it just sells itself as the cheaper option...and in JIRA's case the much cheaper option.

bah...I told myself to not get into this one...total can of worms. However, $800 for writing a commercial plugin and supporting it across multiple versions of JIRA is an odd price point to get bothered by. For most consultants and administrators supporting JIRA that's less than one days wages, at least their billable wages.

Best of luck.

@brett.ryan I also wish some of the plugins were standard functionality. But I can imagine why Atlassian would want to encourage a wider ecosystem to provide them. It's tough to make a living just by selling plugins though.

mdoar, I appreciate the work that plugin authors put in to create plugins, though I have to say that due to many of the pricing structures surrounding them it does make it hard for many of us to convince our management to purchase licenses for plugins, especially when management only see the added functionality as something that should have been present in the first place.

As an example, our management will only entertain a plugin if both the plugin benefits the business as a whole; and that the plugin is priced fairly to benefit the business as a whole.

In a situation where JIRA is used as a service centre implementation then most plugins only affect those managing the system, not those using the system.

Expensive? Compared to a $10 starter license, maybe. Compared with enterprise license costs, not really.

Please tell me this isn't off the planning board permanently. Couldn't Atlassian come up with a plugin? Quisapps was able to make a plugin - which I would grab in a heartbeat if it wasn't so bloody expensive. ($800??)

You'd have to ask Jamie over on the Behaviours plugin pages

Matt, is it possible to control Field level security (for specific roles) by using Behavior plugin? I don't think it is possible in role level!

Thanks Matt. Behaviours looks interesting. To my knowledge you can remove fields from the display, like time spent...which is helpful but I don't think you can do it by role and I don't think behaviours has the ability to keep worklog entries from going into the activity stream. Hope I'm wrong.

Regarding the clarity of Atlassian's business decision, you're correct, its very clear. I was just hoping they had revised their decision.

I appreciate your feedback and suggestion to look into the behaviours plugin.

I think the description is a clear statement of Atlassian's business decision about this.
Moving on, I use the Behaviours plugin to do this kind of thing.

Atlassian?...some sort of acknowledgement would be nice. Specifically, exposing worklogs to clients is simply not reasonable. With some of the nice plugins, like Tempo, Jira could be more tightly integrated into our accounting/billing workflow if this issue was addressed. Until its fixed Jira cannot be used as the business tool that I believe it can be. I'd be interest in understanding if its on the roadmap. ~Thanks.

It's 2012 now and I think its time we had this feature implemented!

since voting looks disabled - i vote for it by comment!

I totally agree with Bob. I "rebuilding Jira from scratch" is the only way of providing field level security I would remove my vote as well.

The Quisapps plugin gives field security for customfields and the timereporting only. All system fields are out of scope. I definitely don't want to gainsay that this is a great plugin (I am using it myself) but from what I see the reason for the missing support of system fields can be found in Atlassian's explanation of why they would not resolve this issue.

Voting is only one consideration! I think I voted for this a long time ago, but I would not prioritize this issue over a lots of other enhancements. Especially given the analysis that Atlassian has done regarding costs. Knowing the cost and other negative impacts to the product, I would un-vote for this item.

"You are proud that version 4.4 satisfy 1400 votes. "

*What do you mean by that? Was this a mistake? Did you mean to say "We are proud..." because I am not...

Please reopen issue and watch how number of wotes will be growing

*I do not have the permission to reopen this ticket. Please do that for me.

JIRA 4.4 available today - deep dive: useful information everywhere
Atlassian is thrilled to announce the release of JIRA 4.4 - our biggest JIRA release in years - satisfying over 1,400 votes! The JIRA dev team has been working hard to get in time-saving and productivity features for JIRA admins and end users alike.

*Please do me a favor and leave out marketing sentence like these out of the discussion.

Finally: Atlassian promised to reevaluate that tike 18 month later (from the point of 30/Oct/07 6:25 PM) - this is now almost 4 years ago. Can you please have your colleagues do this now. I am sure the 400 votes still apply as it is still not solved.

Please look at the attached image: It contains a query result on your own jira that shows that only 7 requests have higher votes. Most of the requests are very old. I wonder why you haven't finally picked up those as important requirements of your customers especially if it turns out that even third parties are able to fulfill those.

The problem of those third parties is that they solved one issue for the price of typically 10% of Jira which is a bad relation in terms of cost. To me any most of the highest request do make sense.

Atlassian,

You are proud that version 4.4 satisfy 1400 votes. But field security feature is voted 440 times. That means over 30% votes included in version 4.4! And remark that currently users can not vote this issue - because it is resolved. Please reopen issue and watch how number of wotes will be growing, showing that this one feature is more important for users than other...

cit.
JIRA 4.4 available today - deep dive: useful information everywhere
Atlassian is thrilled to announce the release of JIRA 4.4 - our biggest JIRA release in years - satisfying over 1,400 votes! The JIRA dev team has been working hard to get in time-saving and productivity features for JIRA admins and end users alike.

I really can't believe why a company like Quisapps is able to provide a plugin (see https://plugins.atlassian.com/plugin/details/23216) that fullfills mostly all the needs that are requested here but Atlassian itself cannot. I really appreciate they did it but the price for an extension like this is about 10% of what Jira costs only because you are not providing this absolutely necessary functionality.

I really appreciated if Atlassian again thinks about providing this functionality as to me there seems to be a pragmatic, technical solution that most of all would help.

Hi,

In an effort to be more productive, I try to only check email a few times each day. I should be able to get back to you fairly soon, but if you need my attention immediately, you can reach me here:

https://fusionary.awayfind.com/jbaty

You can also send an email to support@fusionary.com and someone else may be able to help you.

Jack Baty

–

Opt out of future auto-replies: http://orchant.awayfind.com/oo?h=63d74a25&e=2c376311

My company is evaluating JIRA, and this missing feature is a big hit in our decision. =(

I agree that Atlassian should look at the plugin, but if they use it then they are responsible for it.

~Matt

Here's a thought... maybe Atlassian could negotiate a purchase of that plugin so we can get it for free. It will appease most of the users who want the functionality, without tying up their developers, and probably much cheaper too. Atlassian don't have to be responsible for it.

We need this feature too. Hope it will be put back on your table some time later. Thanks.

Patrick, I totally agree. Working in a small developer team for an enterprise company it is next to impossible to raise capital for anything let alone a plugin to provide something to the business which will not only be invisible to business users using the system but to be a feature they would consider core if at all.

Our company only uses JIRA by the majority to create tickets for problems and click a button to approve QA, but the pricing model includes them as a core user which has to be counted with olivine too. If we were to need to pay for all the missing "core" features the business would order us to find an alternative.

Don't get me wrong, JIRA is great and I want to continue using, but please understand where we are coming from, the few core missing will eventually outweigh the whole!

So, supposedly this feature would take years to be implemented ?
Then how come someone achieved to make this plugin : https://plugins.atlassian.com/plugin/details/23216 ?!
Excuse me if I seem harsh, but this is just ridiculous.

I wish I could try that option, though since it was so hard convincing management to buy licenses for JIRA and confluence they do not want to pay extra for something the business sees no financial gain in it's use.

Seriously, we pay a fairly high price for JIRA, shouldn't this sort of basic functionality be available out of the box?

Initially I was quite worried about it because it deals with some core files of JIRA, but now I've been testing and using the "Custom Field Security Plugin" from Quisapps for about a month and I must say me and my colleagues are really happy about it.
The plugin has met our need of hiding the estimations and work logs to some specific users, allowing us to share JIRA to other offices and partners inside our company, and had almost no side effects.
I would also like to remark that Quisapps is guaranteeing us a great level of support by answering quickly and professionally to all our requests.
In conclusion it could still be improved but we surely recommend it!

Has anybody experiences with the mentioned "Custom Field Security Plugin" from Quisapps? Would like to share...
Kind regards,
mbnm

Hi everybody,

I'm glad to announce the release of the Custom Field Security Plugin, which is targeted to resolve this issue. With this plugin you will be able to set read permissions to any custom field in your JIRA instance, including the fields that already exist. Here's the plugin page at Atlassian Plugin Exchange.

More info is available at the project's Wiki Space.

I will be happy to answer any questions by the email: shchagin@quisapps.com. If you think the plugin lacks any function, feel free to contact me either.

BR, Alexander
http://quisapps.com

This would be a really nice feature to have.

Hi Simone Ferrari,

I have added the new plugin file in the page http://confluence.atlassian.com/display/CODEGEIST/JIRA+Customfields+with+field+level+security to support 3.13.x .. there was a minor change in the API from 3.13 to 4.x in that Atlassian introduced a new param called FieldVisibilityManager for the constructor of MultiUserPicker.

Please try this and let me know if there are any issues.

Thanks
Balaram.
+919535365012

There is a third party plugin Behaviours Plugin that some administrators might find useful for configuring fields with 'read only' mode for some of their JIRA users.

Hello,

I have updated the URL in Brett's comment to reflect the proper page for the workaround:

It was:

http://confluence.atlassian.com/display/JIRAEXT/Using+a+Workflow+to+control+edit+of+issue+fields

However it should be:

http://confluence.atlassian.com/pages/viewpage.action?pageId=149834

Cheers,
Jon

Hello,
it's an interesting plugin.

But when I start Tomcat, system gives me an error that I can also see in the Plugin Section in JIRA:

Error: There was a problem loading the descriptor for module 'customfield-type' in plugin 'Custom Fields with Security Levels'. Error retrieving dependency of class: com.fiberlink.jira.plugin.customfields.RestrictedMultiUserCFType. Missing class: com/atlassian/jira/web/FieldVisibilityManager

How can I resolve this problem ?
Is it already corrected ?

My Jira version is 3.13.5

hello all,

i have developed a group 11 customfields which are derived from the base fields on which you can apply field level restrictions please follow the instructions given in the follow page

http://confluence.atlassian.com/display/CODEGEIST/JIRA+Customfields+with+field+level+security

Hi guys,

We would also like to see this feature implemented, as we think that field-level security is relevant several JIRA use cases - especially when dealing with external users that should see only a limited selection of fields and info from JIRA.

However, as we could not wait for the feature to be implemented, we have developed a so-called "JIRA Proxy" (working title) which acts as a proxy in between JIRA and clients using the web-based JIRA user interface.

Clients interacting with the JIRA Proxy will see a user interface similar to the ordinary JIRA user interface (or a subset hereof), where the proxy will have stripped out chosen fields on-the-fly. The proxy is usually configured with a field control list in which one may specify which fields are allowed to propagate through to the clients using the proxy. Only those explicitly described will propagate, which makes it somewhat resilient to administrators adding new issue fields from time to time

Thus, eg. internal users in an organisation may use the normal JIRA web interface whereas external users interact with JIRA through the proxy, seeing only fields and interfaces they're meant to see.

Using the proxy also helps eg. integrating JIRA into a customer portal, as the different JIRA interfaces may be altered/re-written on-the-fly and non-relevant boxes, text etc. stripped out of the interface and others added. Configuration of the proxy may be performed in real-time and without a need for eg. re-compilation and deployment.

We have not yet marketed the JIRA Proxy as a product, but we have it working and in use with customers, and we have plans for rolling it out relatively soon.

It should be said that the proxy doesn't solve the issues pertaining to field level security in JIRA itself, but in certain cases it may prove useful and remove some obstacles hindering broader adoption of JIRA.

We still have some issues to resolve before it's matured to the level of being an off-the-shelf product, but in case anyone here is in need of field-level security, we would suggest that you contact me and have a chat about what's possible (look for the mail address in my profile).

Cheers,
Thomas Peter Berntsen
Translucent ApS

dito to the former comments
"reappraise the situation in 18 months time ..."

Now it is May 09 from Oct 07 thats >= 18 month ... and?

I bet you can make these changes using a few files compiled in external-source and then not have to rebuild JIRA

~Matt

The requirement is to prevent some users to see some fields, everywhere it is possible to do so.
So technically it could be : hide fields to a group (or only allow to a group), everywhere possible, but at least in the detail/view (create/view, edit/view are optionals as those users will probably not have the right to create or edit issues anyway).

Olivier, unfortunately, no, our requirement is only to limit edit permission of some fields in some groups, so I didn't investigate how to implement view permission (Btw, I saw there was a workaround to restrict edit permission, but I don't want to introduce complex workflow).
What's your detail requirements? Only show fields to some groups when edit/view issue detail/view change log/search?