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?

Samuel, this is wonderful, thanks for sharing !!
Your timing is perfect as my company is planning to open Jira to our partners in the weeks to come !

Looking at your installation steps, I can see that your are modifying CreateIssue and EditIssue.
For our use case, we would also like to limit the permission when viewing an issue. Is this part of your patch? (I'm sorry I'm not familiar at all with the JIRA Architecture/API)

Steps:
1. Put attached FieldPermissionHelper.java and FieldPermissionContext.java under enterprise-source\jira\src\java\com\atlassian\jira\permission;
2. Modify CreateIssueDetails.java (under enterprise-source\jira\src\java\com\atlassian\jira\web\action\issue): add "import com.atlassian.jira.permission.FieldPermissionHelper;" in import section, add "FieldPermissionHelper.checkPermissions(getFieldScreenRenderer(), getIssueObject(), getCustomFieldValuesHolder(), getRemoteUser(), this);" before "checkAttachments();" in method doValidation().
3. Modify EditIssue.java (under same place as above), add "import com.atlassian.jira.permission.FieldPermissionHelper;" in import section, add "FieldPermissionHelper.checkPermissions(getFieldScreenRenderer(), getIssueObject(), getCustomFieldValuesHolder(), getRemoteUser(), this);" before "checkAttachments();" in method doValidation().
4. Modify content in method checkPermissions in file FieldPermissionHelper.java to meet your requirements.
5. Rebuild JIRA.

We're using JIRA 3.10.2.

Sure, patches and source code would be great!

To all who are still waiting this feature, we developed our own simplified version to meet our requirement: Manager wants to limit edit permission of some fields in some groups.
This needs patching JIRA.
Below is my comment in codes.

/**

• ENGR-111775 Field Permission in JIRA
• This is a quick hack to have field level permission,
• Atlassian announced that they wouldn't fix it due to complex, see http://jira.atlassian.com/browse/JRA-1330
• I think a hack can meet our simple requirements, don't need to make it flexible and complete like a product.
• The limitation of current implemention:
• 1. Not flexible, group names are hard coded.
• 2. It determines permission based on field and group, no others, it would be good to have like project involved.
• 3. Seems codes for bulk edit need update too, but this is a little complicated part, so I leave it.
• In the future, if we have more requirements, or need to change quick, then follow enhance solution below:
• 1. Create a new type of scheme, say FieldLevelPermissionScheme, it can be associated with project
• 2. In this scheme, we can associate fields with groups and users on fly.
• 3. Introduce the permission checking into bulk edit.
• @author Samuel Cai
  *
  */

I think this would be a great feature too.
Bye
stefano

Hi,

I agree with reevaluating to fix this issue.

In our company most end-users says Jira is not user-friendly like others tools which more easy for them. I think that the ability to hide some field can help to make Jira more User-friendly.

Ferran

Hi.
We are still in the process of evaluating the Enterprise version of JIRA and has up till now proved to be very promising. But the lack of field level security permissions will mean that we cannot directly share our testing and bug tracking information with our external customers. This is a real shame because having an all-in-one solution would keep bug resolution streamlined and not require any manpower. It seems a big shame that we would have to resort to exporting information into Excel files to email to our customers, asking them to fill them in to then have to copy and paste the information back in JIRA.

I accept that the very structure and basic design philosophy of JIRA may make this feature impractical to implement, and appreciate that it's not necessarily a cost or time problem, but a more fundamental limitation of what can be done without an entire rewrite. But nonetheless, it's a shame as otherwise I would see this as a truly enterprise class product which can be used with customers' direct input.

I will continue to look for altenatives....

Hi! Jira is a great concept, but some impossible little features do this system inflexible and clumsy. I suggest that You working only with top voted issues. But a lot of issues with no top votes are important for us, and for another users. I'm your client - and I'm pay for support not top voted issues, but for my important issues

Well Atlassian, I think you know already what I think about this and the direction of the JIRA development focus. If you have a lack of manpower why don´t you look abroad, Kina, India, Russia and some other countries have excellent developers, why not have a go with them? I´m getting really tired of all workarounds and hokus pokus to get things work as we want.

I think most customers are willing to pay more than the "shareware" fee to use this system if you start giving us what we need and want. Stating that you have flat decided not to implement Field Level Security allthough a massive request for this FR have been reported from your customers is a very strange behavior. I think you need to reevaluate your decision.

//Michael

We miss this feature as well after switching from TTPro ;( Makes the internal vs. client security tough.

When the system works like your setup here where everybody can log in and you do not have to hide one user/client from the other than it is great.
However, in our case where we have to protect the identities of our clients and hide internal testing/development data it is very cumbersome.

You can also separate "resolving an issue" and "setting the fix version" into two separate actions:

• Create a screen for resolving issues that does not have the fix version on the "resolve issue" screen.
• Modify the workflow to use the new screen.
• Add a workflow step to the "resolved" and "closed" statuses that:
  • Has a minimal new screen definition with only the fix version and a comment field (and maybe the summary) on it.
  • Can only be executed by folks in a particular group
  • Returns back to the same status ("closed" remains "closed", "resolved" remains "resolved")

You can solve a lot of these kinds of problems by creating custom workflows that contain restricted fields on a screen that can only be executed by a subset of users.

Now if only we could search for "resolved issues without a fix version" but that's a subject for another issue.

To have the ability to Resolve or Reopen an issue separated from assigning a Fix Version, you can use a custom workflow. Compare
http://confluence.atlassian.com/pages/viewpage.action?pageId=151520521

Aleksei,

Any chance of you attaching your patches to this issue for myself and others? Also, the single-word and single-xml templates have references to timetracking. I think these are what is used to display a single issue as Word or XML.

~Matt

Aleksei,
what's your status? Did you make any progress with email notifications and reports?

Yes, I've managed this as well.

• atlassian-jira\WEB-INF\classes\templates\jira\issue\table\macros.vm (issue-table)

Must be patched to hide field values for these fields.

I think this must be hidden in further reports as well. I'll investigate more and report back.

Time tracking info is also in the issue navigator (after you customize it). Can you hide/disable fields Original Estimate, Time Spent, Remaining Estimate and Progress from there?

This still can be done with a rather pragmatic solution:

1. Create jira-timetracking user group. Only users from this group may see time tracking information
2. Patch JIRA templates which have something to do with timetracking to check if current user belongs to a group or not:

http://confluence.atlassian.com/display/JIRA/Customising+interface+based+on+user%27s+role

I could identify a number of templates/files which have to be patched:

• atlassian-jira\template\standard\timetrackinginfo.jsp (time tracking table on the top of the issue screen)
• atlassian-jira\WEB-INF\classes\templates\plugins\jira\issuetabpanels\worklog.vm (work log tab in the issue screen)
• atlassian-jira\WEB-INF\classes\templates\plugins\jira\issuetabpanels\changehistory.vm (change history tab in the issue screen)
• atlassian-jira\WEB-INF\classes\templates\jira\issue\field\timetracking-edit.vm (estimated time editor)
• atlassian-jira\WEB-INF\classes\templates\jira\issue\field\timetracking-view.vm (estimated time viewer)

There are also references in notification e-mails, but since they are also vm-template based there's not problem in hacking them as well.

I've patched the files I've listed above and I could really achieve that a user which is not a member of jira-timetracking group does not see the time tracking information.

I'l work more to apply this approach to e-mail notifications as well.

Maybe a compromise is to create groups of fields that our tied together. The one area that we would like to hide from the outside world is our time estimates and actual time spent. This is internal project management stuff. So maybe it would make sense to create 2 or 3 security roles that you can assign fields to that are then handled properly. It isn't perfect, but would probably satisfy the 80/20 rule and be reasonable to program into the system.

> Poll@Other_Enterprise_Customers_around_here: "Would you be willing to pay more, to get this feature?

Maybe, probably.

I am with Nicolas on this. We don't need it thát bad - Jira is still a great tool - but it would make it a 'better' tool.

> Poll@Other_Enterprise_Customers_around_here: "Would you be willing to pay more, to get this feature?"

No. We don't need it for what we use Jira for here. It's a nice-to-have on one of the instances we have, and I wrote a custom-field to provide a good-enough solution for one field on the second, but the other three don't need it at all.

However, it is blocking wider adoption of Jira as a general tool. If we were looking to replace our helpdesk software (and it's a shame we aren't because it is awful), or we had external customers, then we would need it, and a $1000 price tag wouldn't be an issue. We're in a catch-22 though - we'd need to see it working before we bought it, and there's no guarantee we'd buy.

Poll@Other_Enterprise_Customers_around_here: "Would you be willing to pay more, to get this feature?"

YES

Maybe Atlassian could introduce an "Enterprise+ (say Call Center Functionality or something similar)" license. If there are only 500 JIRA customers that would pay yearly US$ 1000 for the support license, Atlassian would get US$ 1 Million in TWO years - is this a good motivation for the beginning? Not to talk about the image ("yes they are good and nice, but not capable of blabla ..."). Otehrwise Atlassian WILL certainly loose many of their enterprise customers - so <dear Atlassian-Team/Management please go for an innovative future-oriented strategy!> If we do not get this functionality in the nearest future we are forced to consider other tools - sorry...

In the first i want to say (like many others here) that i am very disappointed and many of my coworkers and projectmanagers were eagerly waiting for this feature and it was one of our main reasons to renew the maintenance license. All of the features in JIRA since 3.8 were only "nice to have" for us. There was not much work being done to the things which we were really waiting for.

Ok, enough of flaming - though it is true.

On the positive side, i want to ask 2 very concise questions and hope to get a an answer from you Atlassians.

Question1:
Hiding timetracking-information is one of the more important things for us, we want to hide. Is implementing this feature alone less work than the "whole thing", or is it so much connected to all the other field-rendering, that it is almost the same work?

Question2:
Field-Level-Security would give JIRA a real boost in functionality and i think also in sales, as it is one featiure many companies have on their list for selecting a software. Couldn't you think of hiring more manpower for development for getting this feature done. payed by the "future" revenues?

Another Question?
How much more expensive would JIRA have to be for each Enterprise Customer for you to get the money you need to hire the manpower to get this feature done, without having to stop everything else?

I think i can assure you, that many of us enterprise customers are really WILLING TO PAY MORE to get this thing done. What do you think of this option?

Poll@Other_Enterprise_Customers_around_here: "Would you be willing to pay more, to get this feature?"
(taking into account, that JIRA is still comparatively cheap, when lookting at other products)

I'd like to suggest a workaround implementation that might be suitable for the internal vs client use cases.

We are using JIRA since a short period and we are probably using only 10% of all the features, therefore this solution may be incompatible with some features we are not aware of. Any way, here it is :

Develop a super text field renderer that would encapsulate any of the available text field renderer
This renderer would have two options :

• the "real" text field renderer to use (and its options, if any)
• a group indicating the users authorized (or not) to view the field

It would probably still leave timetracking, worklog, svn/cvs and others fields like this visible to all, but it's a workaround...
What do you think ? do you think it is feasible ?

We could probably do it in our company... but as we have never developed anything using JIRA, it would probably take us much more time than it should.
Could Atlassian, or any other plugin developer, provide such a thing ?

Olivier

Looking at the change history, I do note that the issue was never actually scheduled to be in a release - do we assume because we vote on it that it automatically gets done? JIRA is a product - you download it, evaluate it and make a decision to purchase based on what you see fit as a solution for your environment. It is not a service offering that implements every feature request. It is a 5k product, sold as-is - and a good 5k spent at that.

It is difficult to write a product to be everything to everyone, and knowing the team at Atlassian - I know they'll learn from this. There is nothing sinister or deceitful here, just a company that has grown tremendously over the last few years and have managed to produce some brilliant products. Good on them for going back through the 'too hard basket' that gets left when you grow and coming back to this issue and updating it - they could have easily just left it hanging or timed it for the christmas break to cover it up from a PR perspective. Look at the alternatives out there - do they offer the same amount of transparency? With Atlassian, what you see is what you get.

OK, now to add some value:

There are ways to achieve some level of this feature, but they are generally solution specific workarounds and not generic enough to be nicely made into the product. Some things we have done for our customers previously:

• Create a CFType, control your velocity templates for edit, create, column view, etc with permissions and make a core mod to remove the history tab from non-authorised users
• Create a simplfied UI using the webservices API for basic users to add & view their own issues.

regards,

-Rob
http://confluence.atlassian.com/x/XrAC

On behalf of Polycom, I'd like to send a little love back to Atlassian. Don't get me wrong - we wanted FLS badly, too, for the customer-facing piece of our app. And we're not a small customer - nearly 100,000 issues, 90 projects with all their own workflows, field configs, permissions, screens, etc and roughly 500 concurrent users out of a total userbase of 2,500 (internal, partners, customers)

But I keep this in perspective. This product is so cheap they're nearly paying us to take it. We rolled it out worldwide in a couple months and currently support it with a single employee, even though we also have integration with 4 source control systems and Siebel CRM. I think we use every feature of JIRA extensively. Considering all that it does for so little (time and money invested), I'm still wholeheartedly impressed!

And to the point of customer satisfaction... Atlassian DOES truly offer world class customer support.

• They have always answered our support tickets in less than 48 hrs (often – in under 24).
• They offer Live Help and those guys are truly knowledgeable
• They do user conferences. The one I attended in Palo Alto was really insightful and great for networking with our customers.
• Their documentation rocks.
• They offer customer face-to-face time. If you're a customer who's up in arms about this feature and considering dropping JIRA for another product, I urge you to call up Atlassian to discuss it. Or write me..(joanna.thurmann@polycom.com) and I'll buy you coffee in San Jose.

Don't give up on the product or the company. Like Mike Cannon-Brookes wrote in his blog, they're open, honest, hard-working and sensible. Only thing they might need is a few more like-minded developers (kudos to folks like Anton) and key features will be slam-dunked into every release.

Hi,

I have updated the workaround instructions:
http://confluence.atlassian.com/display/JIRAEXT/Using+a+Workflow+to+control+edit+of+issue+fields

Please note that the following instructions do not provide a complete solution to Field Level Permissions, but allow to control who can edit particular fields. The workaround does not provide a solution for restricting who can see the values of fields. However, I hope that some of you will find it useful.

Cheers,
Anton

could you at least update the proposed workaround page, by showing how to use the utlimate workflow abilities?

as it is now, it is just a shame to mention it as our solution.

thanks

I'm really disappointed about this "solution" !

I think that your blog does add some more information on the thinking behind this decision and I'm glad that you stood up and said it. I particularly like the personal slant - your natural language emphasises the way you feel rather well.

I am quite neutral on this particular improvement - for my clients, FLS is a nice-to-have but totally not essential. If we wanted to use Jira to replace our helpdesk systems, it would be critical, but our dinosaur MegaCorp(tm) processes lock us into inefficient patterns of using mostly bad software "because that's the way we do it". FLS is one of the few weaknesses that Jira has, but the dinosaurs are good at spotting this and stopping us using Jira to replace them.

But it is an excellent issue tracker, and we're using it for all sorts of tracking - it's grown way beyond just "issue". We use it for deployments, development issues, incidents (helpdesk records the initial call, but fails on the 3rd line detail), environment tracking, to-do lists, Risks, change requests, analysis, and I'm sure my colleagues could add more.

I applaud Atlassian for finally saying what they're going to do about it, even though it's a flat-out "no". You earn bonus points for saying that although you've said "no" now, you still don't rule it out and have pencilled in a "have another look" in 18 months.

But (and you knew there was a "But" on the way), I'd like to see the other "most popular" items dealt with too - whether the response is "not this year", "never" or "maybe". It is starting to feel like Atlassian has given up on its users - for most of us, nothing overwhelmingly useful has been implemented since 3.6 and you've just shot down the one single most requested feature since 3.0.0 was announced. Now that FLS has been ruled out, is there any chance of any other requests being investigated?

Guys - I'd like to personally say thanks for all your comments - the flames included. Nothing here is easy and we are listening.

I started writing a really long comment here, but it seemed better as a blog post so I've put it up on my personal blog instead - Parenthood, Product Management and Pain.

I suggest you read that to get a lot more depth behind our decision. I hope it adds somewhat to the understanding, even if it's not the solution many are looking for.

Beyond that - I'm happy to respond personally to any questions by email, here or on my blog.

> > Atlassian have effectively withdrawn from the helpdesk/support market.

> That's what I've been saying all along.

Yep, one of your posts ages ago was why I said it.

Atlassian have effectively withdrawn from the helpdesk/support market.

That's what I've been saying all along. I don't think JIRA was ever intended to be a helpdesk application. The problem is their application is so good and well priced, that it is so close to being a helpdesk application, we'd like it to get the last steps to get there. I say that even though it is my helpdesk application.

I think there's always been and still is a big market for internal issue trackers, which I assume was always their target audience. Here's the things I don't understand:
Why did Atlassian put in some of the hiding capabilities (e.g. in comment viewing) in the first place?

1. The development time and effort required to achieve it would be massive (12/18 months +)
2. It would totally monopolise the engineering team and NO other features or reworks would be delivered during that period

If you can't take the heat, stay out of the kitchen. You want to be 'the' enterprise solution? Then this is what branching is for.

I had quite a detailed look into field-level security a while ago. I can understand why Atlassian have chosen to cross it off the list from a technical perspective - the scale of the changes required scared the heck out of me. The main problem was that you'd need to make huge structural changes to the back-end before you could make any field secure, and then pushing the changes through to the front end would be a nightmare as well. It's not just a case of hide/read-only/edit access to a field, you need to insert the decision process into so many outputs - history, email, word, excel, rss, xml etc.

But I got the feeling that if you could implement it for one field, then extending it for others would actually be quite easy. For example, once the infrastructure was there to support (say) field security on "free text" custom fields, then adding it in for "date" or "short text" etc would be a doddle. Same goes for system fields - once you could secure "resolution", extending it to "priority", "assignee" and "time tracking" becomes easy.

However, I'm in two minds about the logic behind this decision. I'm glad that Atlassian have finally decided what they're going to do. I understand the choice from the technical side. I'm not going to pretend that I understand the decision to lose that many customers (new and existing), that's an internal matter. Field level security for most of my existing clients isn't that important, but it is preventing wider adoption in some cases. I do worry that by doing this, Atlassian have effectively withdrawn from the helpdesk/support market.

All I can hope is that now that the really big change has been ruled out, and Atlassian (hopefully) feel guilty about letting so many of us down, they get on and concentrate on improving Jira for its main function - issue tracking. If I were them, I would start by dealing with some of the other 9 top requests - none of those look like they are anywhere close to the difficulty level of field security (disclaimer - I've voted for 7 of them as definite winners for my clients). My clients have seen no reason to move forwards since 3.6, so they're thinking about skipping renewal next year, but if a couple of the top items get done soon, I could still sell it.

We don't want our customers to see who is assignee because we have the helpdesk as single point of contact. To me it seems logical that some fields may not be seen by everybody, so field level security is important.

I believe that individual field security is more than most/all of us need. For example, I don't need to hide the issue ID from anyone. I am sure the full implementation, field level security, would be huge and truly overkill.

That being said, I think a coarser grained solution would be better. There are some key groups of fields that we need to be able to hide, such as time tracking information (covered in JRA-2364) and custom fields, which we use for our budgeting/approval process. What do others truly need for their installations?

Could the Screens configuration be extended to cover most of this functionality? I know the issue navigator would need updates as well as email notifications, but it might be a simpler solution...

"In my opinion, another company has paid to Atlassian some quite good money for not implementing this.
And yes, that makes sense... it is business."

Conspiracy theories?? Are you kidding me?

Though I'm very disappointed and Atlassian shouldn't have let this drag on for this may years,* I applaud them for at least making a decision, a decision that in their opinion is in the best interest of the product*. How many times have you been strong armed to produce a feature that our constituants have choosen to not listen to the downstream consequences? Then six months later the same people are complaining about all of the things you warned them about. Just like parents, we need to make the best decisions for our children. Hopefully they made the best decision.

It's time to move on, re-raise your more specific issues and if Jira doesn't fit your need without this feature, go find another tool. Again, I applaud Atlassian for not falling into the be everything to everybody trap.

In my opinion, another company has paid to Atlassian some quite good money for not implementing this.
And yes, that makes sense... it is business.

Very disappointing.

Truly incredible. However, I'm going to save my comments on the quality of the product management exhibited for another forum.

TO ALL who have previously opened narrower issues that were closed as "Duplicates" because of this issue:

Please REOPEN your issues now that they are no longer duplicates. I'd do it for you if I could.

Let's give product management the opportunity to atone for this error in judgement by concretely responding to each of the various crucial sub-cases. After all, we know that these requirements matter to making JIRA what it could be - a truly enterprise class product.

Very disappointing. We were depending on this feature and the workarounds don't seem to cut it. I will be looking into other issue tracking applications. (This is not the way to treat your customers)

I can see version 4.0 appeared in JIRA release map.
I assume changing major version always means something "revolutionary".
So far, nothing of highly voted I can see in the list for 4.0
Sergiy.

I'm just as disappointed as the last 10000+ users on the outcome of this issue. But besides the more direct consequences of the failure to implement field level security, other more disturbingly JIRA problems start to shown themselves.

The idea of using JIRA for effective customer issue communication has failed on this issue. Atlassian should be an example of the very best usage of JIRA to leverage this aspect of JIRA's powers. Until now I have slept peacefully each night knowing there existed a JIRA implementation, which provided near perfect issue communication with the customer. I only had to work towards achieving the same level of JIRA usage, to provide effective issue tracking. This illusion is shattered.

I've just upgraded from JIRA 3.7 to 3.11 and I am a bit disappointed of the difference, it's mostly details that have been changed. Now we hear that more fundamental upgrades are impossible, because of the JIRA architecture. This leads me to severely limited my expectations of future improvements to JIRA.

Conclusion: Until now I have been aggressively pushing usage of our JIRA (and Confluence) installations to the development projects (in the role of tooling responsible). The perspectives of the inability to handle and resolve JRA-1330 in any satisfactory manor is seriously challenging this strategy.

Although I don't think some recent customer comments are very helpful or constructive, it's not surprising that people vent their frustrations here since there seems to be no other way to give feedback. This is also made worse by the fact that Atlassian rarely reply with any information which contributes to the feeling that they do not value their customers.

This is, or should I say was the number 1 requested issue by far and the fact that after all this time, Atlassian now come out of the woodwork and drop this bombshell is just unbelievable!

Atlassian, do not be surprised by the backlash you are now getting. Suddenly you tell us that you had customer meetings, reviews, discussions etc.. etc.. If you had at least told us this was going on, some of us might have been more sympathetic.

I'm sorry, but I feel this was very badly handled.

Andrew

It took four and a half years to say - Won't Fix
Sad

Nice timing!
So you were just waiting until I renewed my support licence (for the last time).

The thing is... does this reaction from Atlassian actually surprise anyone, any more?

disappointment

We are happy with Jira as an internal issue tracker, but we need a client facing system as well. Jira has most of what's required (flexible permissions, flexible workflow, email integration, etc). I do understand that a generic solution is very complex to implement, but being able to hide some fields (time tracking information, assignee and some custom fields in our case) is really the missing piece in the puzzle.

I think the workarounds presented by Eric S. / Brett Jackson do not really hide the critical fields everywhere. Wouldn't time tracking info and assignee still be available in the issue navigator, issue history, emails, etc.?

Like Neal, I didn't see any truly helpful new features in the last year or so, since "project groups" in 3.7. I'll have a hard time justifing the next renewal of our enterprise support licenense here.

This is extremely disappointing !

Disregarding customers needs this way is completely incredible.
More than 400 Jira users (which to be fair probably represents halft customers) have expressed their need on this. Not responding to this issue in ANY WAY is totally inadmissible. Jira customers will never be able to open their issues tracker to their clients without this (thus preventing a more widespread adoption of the product...).

I also agree with one of the parent that marking this issue as "won't fix" is sending us packing ! You should at least provide a decent workaround till your complete and proper implementation gets ready.

After talking with our staff here, if this issue does not get adress, we will seriously consider dropping Jira in a short time !
As said by someone else above, this is pitiful.

I think that a specific solution for the Time Tracking fields could satisfy a number (30%, 50%, 70%, ...) of the voters/watchers.
These fields are already specific (original field shown until a first worklog then replaced by remaining estimate, ...)

Of course I will prefer a global solution, but I could understand the complexity to implement it. So, maybe step by step...

Such a pitty!.

UNBELIEVABLE. I would never expect this approach from a company like Atlassian.

Under normal circumstances this should cause an instant dismissal from the product manager (unless he/she co-owns the company...).

... we missed the opportunity to address this request and your comments properly earlier

It seems that at the end some decision makers at Atlassian do not understand/accept that this is the MAJOR issue that most of the enterprise customers really need. After 4.5 years it is indeed not enough to give us just few links as a "workaround". As a software company we are sometimes also forced to make unpopular decisions and I can certainly understand some of the Atlassian concerns (e.g. "It would totally monopolise the engineering team and NO other features or reworks would be delivered during that period"). We all must accept that Atlassian can not offer us the ideal solution to the problem - but "Won't fix" is NOT the way to treat at least 400 customers! From my perspective (as a minimal professional and customer friendly movement) Atlassian should identify those sub-features that are important and feasible to implement w/o huge risk/efforts and do their best to deliver official workarounds within a reasonable time.

I second the statements of the other JIRA customers above. For us, this is a major missing feature - especially concerning the ability to hide time tracking from our customers, as Henk Binnendijk has already pointed out. I do hope that at least the JIRA-2364 issue will now (finally!) receive the attention of the JIRA development team.