|
Updated description to better reflect the true intention of this bug.
This issue is very critical to me. If the reporter does not come up with a description, should I then create a new issue or can I supply you with any information?
Please add any additional information as a comment please.
When creating an issue the user sees a list of fields that the user can/has to fill out. Every user that submits an issue is allowed to see and edit all of these fields (except two of them that in some way already has some kind of access permissions set on them: Fix for version and Assigned To).
What I want is to be able to (on a project basis) setup which groups are allowed to see and edit which fields. Here is an example of what I might want to setup:
Developer:
Administrator:
It's exactly what is also required in our organisation : some fields are used by business people, some others by technical people. Business people does not want to see technical fields.
Consequently, in the Field Layout Scheme, we should be able to defined the hide/show/required/edit attributes depending on the user/group/role. Today, these attributes are defined staticly for a project. Our team would also need this feature.
I think that setting specific permissions to fields on a 'per usergroup' base is quite important. Re. severity vs. priority, field-level permissions would be handy, as then bug reporters could be given the "Edit Severity" permission, and only developers given the "Edit/View Priority" permissions.
For our needs we would like to see the ability to Resolve or Reopen an issue separated from assigning a Fix Version/s.
In our implementation we have developers and testers. we would like testers limited to closing and reopening issues, but they lose the ability to reopen if they are not granted field permissions to resolve issues. However, allowing testers to Resolve issues also opens up the ability to assign a Fix Version which we would like to restrict to developers only. This THE MOST WANTED FEATURE in our company.
It would be great to give the field-layout page another coloumn, so that i can "Add Groups" to each field, for which this field is visible. If one user does not belong to any of the groups associated with that field it is not visible. You should really consider it. Can you tell me if something like this is already in your development pipeline? My company (SEB) also really need this feature !
We need to have several people approve an issue before it can reach the next status. For this I have created several fields, e.g. "group 1 approved" (yes/no). At the moment anyone can edit this field. We cope for now, since there is an audit trail (change log), but it would be a lot better to be able to allow access to certain (custom) fields in some form of permission scheme. what's the schedule for this issue? This would be a great feature. We don't want our customers to be presented with fields they don't understand (or, shouldn't be filling out).
Didn't find it first, sorry.
We habe some very critical fields, which should only be updated by authorized people. We really need this feature!
Ditto - my company could really use this feature in the way we aim to effectively use JIRA.
Thanks I have another use case which hopefully will be solved by this enhancement. I want to record for each issue (when I close it) what the source of the issue (if it was a bug) was (e.g. programmer error, incorrect specs, etc.). But I don't want everyone to be able to see this field - I want to use it for internal (within my department) metrics only.
Are there any plans to have this feature anytime in the near future?
We would really aprreciate it to have it in v3.3. (if you don't do it i will be severely damaged by some of my co-workers, who i convinced to buy jira!) Hi Gerd,
Yes we do have plans to address this in the near future. Sorry I can't give a more definite answer at this time. Cheers, Hi Nick -
I am looking for this issue to be addressed in 3.5 as this is what was communicated to me prior to my purchase of the enterprise version. This is still the case - correct? Hi Eric,
At the moment there are plans to address this feature in 3.5 as this is a very popular feature. However these plans are not definite and may be subject to change. We usually do not make definite promises about delivery of features before they are actually scheduled. Thanks, We need it as well:
"Depending on the role of a user, and the current status I want to have several issue fields editable or not. We need this feature as well
It is hard to believe that JIRA doesn't support field-level security. I had been trying to achieve this by playing around with Screens and Workflows (trying to create difference screens for different contexts, with different fields having different permissions.) However, couldn't get that to work and it was too complicated way to do field-level security. We have code that limits viewing/editing to a set of configured groups. We are happy to contribute this to Atlassian or make it available under ASL 2.0.
Alan,
Depending on the code changes, you may like to create a page on Confluence Cheers, My company just launches the Jira for HQ, regional offices & business partners worldwide. Then, many business users request to hide some sensitive fields for external users, e.g. "man-days used" custom field for record actual resources used by assignee.
We have a dilemma that if we disable such fields, we need to duplicate effort in copying same issues in another excel file for recording the "man-days" to avoid being seen by external users. I think field permission should solve this problem. Anton suggested that this might get scheduled for 3.5 – obviously that didn't happen – would it be possible to re-issue an ETA? Being able to hide a few fields would radically change our approach for this project – the alternative is quite awkward.
Our company was also depending on this being in 3.5.
Please give a new estimate for when this functionality will be available. Hi,
Unfortunately, at the moment I am unable to provide an ETA for this feature. As this feature is very popular will be looking at this in the future. However, to stay flexible we plan one release at a time, and this feature will not be part of the next (3.6) release. As soon as we schedule this feature, we will ensure that we will update this ticket. Thanks, Hi,
There is one extension of this functionality that I don't see specifically mentioned: The ability to assign one or more users and or user groups to each field. One size doesn't fit all when it comes to our customers. Supporting the ability to assign multiple users or groups permission to view and edit each field will allow us to display only what each customer wants to see. That will help us keep all of our customers happy, which in turn keeps us happy. Thanks! Chris Hi Anton,
as the upcoming release 3.6 is scheduled for April 2006, I assume the scope definition for 3.7 will start at least in the first half of April. Is this feature already planed for 3.7? Is there an existing workaround which can easily be applied to simulate field level security (e.g. by directly editing the appropriate jsps and restricting permissions to view only a subset of the contained fields/customfields)? Franz Very much needed within our company too!
Our company also want this feature. voted
Hi,
Sorry for the delay in responding, been trying to iron out a few last things for 3.6. We will be planning JIRA 3.7 early next week. At the moment I cannot confirm whether this issue will be scheduled or not. This is the most popular issue, so if not 3.7 then it should be soon after. We have quite a few tasks that we would like to do for JIRA 3.7 which will take quite some time. For example, we would like to make the project administration in JIRA much simpler to use (tone down the emphasis on schemes). Make active workflows editable, so that they actually stop being a royal pain. etc. As far as the work around goes, I think the only real solution at the moment is to code up a custom field with the security logic in it. See the 'Admin-only editable field' example in our tutorial: Please note that the change items for the field will still appear for anyone who can see the issue. The custom field example only addresses the ability to 'edit' the field. Thanks, My company is using the JIRA over 6 months and there is an urgent need to expose JIRA for external customer BUT we need to hide some sensitive fields for external users, e.g. "customer NAME" or custom field for record actual resources used by assignee.
Can you please provide a hot fix that covers this issue ASAP or at least give us dates when thsi feature will be available... Thanks My company has started using JIRA on all of our projects for issue tracking and project management. We are looking to expose JIRA to external clients so that they can create issues and browse the status of existing issues. However, we do not want to expose any time tracking information to them.
We are looking at ways of hacking the JSPs to prevent the clients from seeing this information, but it is difficult given the number of pages where this could be an issue. (e.g. the changelogs, issue navigator, etc.) We'd really like to see this feature as well as We would much rather have these kinds of features fixed than the administration section, etc. This bug, If you ask me, i would like 3.7 stripped off most other features and improvements and would like to have this feature implemented instead.
That would be really great! OK, since there's so much talk today about this issue, let me add this.
The lack of this feature is the single biggest reason JIRA cannot compete on an equal level with other issue tracking systems used for customer support. JIRA is great for an internal system, but as a helpdesk, there are too many security shortcomings. Just to throw some fuel for the bonfire: We're also very much interested in this feature. It would make a HUGE difference to us. To us, the biggest possible improvements are this, the time tracking issues, and the (related) sub-task time worked rollup.
I haven't installed it yet but I anticipate most of my worklog improvement needs can be smoothed (lubricated?) by the greasemonkey worklog helper. Likewise, I can probably come up with reporting workarounds to the worklog improvements. This issue, however, is the one thing that will be the hardest to deal with. It seems that this feature is especially important for companies who provide software for business customers, like we do. I also can't wait until we can replace crappy separate customer support system with proper direct access to Jira, so totally agree with Gerd and Eric above.
I also would like to stress the importance of this feature. Without it we had to put a number of projects on hold. Please consider implementing it in 3.7.
I would also like to stress the importance of this issue to us. This is the single thing that is holding back the public availibility of our JIRA installation. There are just some (custom) fields that I want to hide from external users
Guys,
I just wanted to let you know that your voices are being heard, even if we don't get a chance to answer each and every one of your comments. We are changing a few things in the development process in the near future, to ensure that we can deliver features faster than we currently do. This will help us complete this (and other ) features faster. Keep adding useful comments here, and use the vote feature to cast your votes. Thanks - and we'll let you know as soon as this is scheduled. I agree with everyone else here, the lack of this feature is causing my management to push very hard to use another issue tracking tool even though JIRA is far superior in nearly every other way.
Our solution to this problem was to make automatically 'sanitized' synthetic reports using scripts. We publish these pages to our confluence site where we give 3rd-party access – they're clean, live-updating, and only took a bit of hacking to cook up.
It aleviated a lot of the headaches management was causing me. We just ran into another problem related to this issue. We want to allow our clients to enter issues into the system, but we don't want them to be able to set a fix version when they enter it. However, we want our employees to be able to enter a fix version when we create issues. The only way we know of to do this now is to take "fix version" off of the create issue screen completely and don't give our clients edit permission.
However, if we had field-level security, we could even allow our clients to create AND edit - but they wouldn't be able to change the fix version on either screen. Jeremy,
We had to solve the same issue at my company. We took the "fix version" off the create issue screen (as well as several others) and we don't give our clients edit permissions. Then we created a workflow transition called "Edit Issue". And associated it with a screen that doesn't contain the fields we don't want clients to edit. I did a write up on the workflow implementation Erik Why would you need to do all that? The Resolve Issue Permission includes the ability to set the FixFor version for issues. (see JRA-9959 also).
Neal,
We do it because we want to be able to assign some issues to clients - thus they need to be able to resolve the issue. But we still don't want them messing around with the scope of a version all willy nilly like and blowing away the schedule/budget (and then blaming us Erik We follow the Scrum software process and use the Fix Version to schedule which sprint (iteration) issues will be tackled in. So, we set the fix versions before issues are resolved, and we don't want our clients to control when we schedule issues to be fixed.
If clients need to be able to resolve issues but should not manipulate the Fix Versions field, would creating a custom workflow where the Resolve Issue operation is not protected by Resolve Issue permission work? This way you can use the Resolve Issue permission to 'protect' the fix for version field only.
We're able to use JIRA effectively at work for software process management, as well as our helpdesk software. In these two use cases, JIRA excels. We'd also like to use JIRA for our project management needs, but this issue seems to be the missing piece of the puzzle. Using a workflow-based workaround is not feasible in our particular situation, so I'm voicing my utmost hopes that this gets implemented soon
 Keep up the good work Atlassian! I, too, see the ability to control view and edit security on a field by field basis as one of the most critical missing pieces. The only other thing I'd really like to see in 3.7 is that bulk-edit of custom fields actually works properly!!
Everything else really doesn't matter as much. Yes, editing active workflows would remove huge headaches for me, but at least that can be handled. These issues are unresolvable without help from Atlassian! Be sure to include time tracking in the scope of this feature. For example:
Like so many others in this thread, this issue is critically important to our company. I'll spare the details because others have already articulated quite clearly why this is needed. Something that may help those of us that are waiting is an understanding of why this much-desired feature has been pushed out so long. It's certainly well-understood on the part of this developer that security changes are always cross-cutting, and I assume that implementing field-level permissioning would have a significant impact on other (perhaps seemingly unrelated) areas of the JIRA codebase.
Is this the case? Whatever details can be provided would be appreciated. I've been thouroghly pleased with both JIRA and Confluence, and I'd like to be able to defend Atlassian (and provide my people with some hope for the future) when the tough questions come at me, like "what do you mean we can't restrict our external customers from modifying issue priority??", etc. Thanks! In my company, a feature which can filter the content of a Multi User picker custom field (based on group or other) is really a need...
For example, if we want to add a custom field called 'Cc' and that we want the filter the content of that field depending on the project, it is at the moment impossible... Just wanted to add my voice to the list. This is not only a necessary feature for users who will give a JIRA front-end to customers, etc, but it is very much an issue for SDLC in my organization. We are looking to enforce a process that will only allow certain groups of users the ability to edit certain fields. If we want to enforce our policy on what fields can be edited by what users, we need this functionality. I just wanted to enforce the idea that this isn't going to only be used by organizations that want to give a front-end to customers, but also by organizations that want to have a standardized SDLC process with the expectation that the tools will help enforce that process.
Thanks to everyone who has commented on this issue. I just wanted to shed some light on our development schedule, and how that impacts this issue.
At the moment we need to clean up the administration of fields before we can implement this feature. At the moment fields are brittle, complicated and difficult to work with. Adding another layer of complexity would not be the right way to attack this. To be honest, this feature will not be implemented until we have cleaned up fields, and that will not happen in 2006. Believe me when I say that we discuss high priority features at every planning meeting, and all the developers on the JIRA team are aware of the status of this particular issue. Cheers, Scott - the attention is much appreciated here, thanks. For my
company's work, we've managed some workarounds in this area. I just wanted to comment here to say that after dealing with this issue for some time, I have a new respect for how difficult this change might be. I'm glad to hear that you'll be tightening up the implementation (and hopefully the admin UI to match) before adding this in. All that having been said, it's still a much desired feature for us. Thanks again. For product companies who want to share their enhancement list with their clients in order to solicit comments and feedback, it would seem very natural to want to restrict access to some fields such that only internal staff could access those. Such fields might include "internal priority", implementation details, impacts to other issues, sensitive issues or concerns such as "we've just realized the problem is much worse than the client realizes..." etc.
It is actually very unusual for a company to be as open as Atlassian. While I admire Atlassian's approach, at many other companies competitive pressures and client management priorities require that some information related to enhancements (and defects) is hidden. Thank you for your note. Please be aware that I will not retrieve e-mails from Tuesday, 26 September 2006 AM until Wednesday, 25 October 2006 AM.
Should your message require urgent attention, please contact: carl.courtie@hansard.com In all other circumstances your message will remain queued for my attention for when I next sign on. Luke Davies field level security is a MUST for us since Mantis has it and we need to migrate from Mantis to Jira
Hi, is there any update on this?
Will this feature be on your list for 2007?
I'd love to see an update on this issue. This issue is currently a roadblock to our purchase of the enterprise version. Please give a "best guess" of when this could be expected.
We are using JIRA in our company for about 6 months.
And I can add to all the above - this feature "field level security" should be top priority! Has anyone found a solution or made a real workaround to this? I came up with the following workaround to restrict who can edit fields, it's not perfect but works for us and may help some of you.
I put the fields I don't want our clients to be able to edit on a separate screen, which is only accessible via a workflow action that is restricted to internal staff. I also set up a Screen Scheme with a default screen (for edit and create) that excludes these fields and a view screen that includes these fields. Screens: Name: Client helpdesk internal screen Name: Client helpdesk view screen Workflow action defined for every step in the workflow: Screen scheme: Some of the downsides are: I think this group deserves a commitment from Atlassian on when the #1 request in Jira is going to be released. Our company is crippled without this feature.
I've been a huge JIRA proponent for several years. My pushing of JIRA at organizations I've worked for has resulted in several copies of JIRA Enterprise being purchased. Unfortunately, due to Atlassian not responding to high priority issues such as this one (also work logging, subtasks, subtask hour rollups, etc.) - I no longer recommend JIRA as an issue tracking/project management tool. We are now using other solutions.
Wow! i am preparing to purchase an enterprise version of this software for internal use across several organizations. The comments on some of these major issues make me pause. I run a software company and if my number one issue was open for over 3 years, i wound not be in business long. I join Tarun on requesting a comment from Atlassian. However i would like a definitive date as to when this issue will be closed.
I'd like to echo what Jeremy said. My recommendations have only been responsible for probably four Jira sales, but that's where it stops for me. IE: I'm not actively recommending it any more.
We had been using Bugzilla at the organisation I am currently at, and I pushed to move to Jira instead, as it was a more polished product, and given we're paying for it, expected a better support experience than "just write it yourself". However that's pretty much what I'm getting from Atlassian too. it's acceptable from Bugzilla, because it's free. Not one bit acceptable from Atlassian. Unless Atlassian get some of these long-outstanding and pretty fundamental issues sorted out, I will begin to plan an exit strategy (back to Bugzilla, and polishing my PERL skills...) It's a shame, because I truly like a lot of what Jira offers, and in a lot of places it's great. But a few areas have been found wanting - nothing wrong with that, software is an iterative process - but these areas seem to have been LEFT wanting. It's strange because Atlassian sound like they're fairly small, and small companies are usually more dynamic in their responses to customer issues. Oh well. Hi,
in my opinion it's really rude, what you're doing here. I'd also liko to have this feature. But I'm a software developer on my own and I can guess what this change would mean because of the really complex structure of jira. And I'd just like to say: I think it's really brave of Atlassian to do this here, allow to vote and comment for issues officially. In other companies you don't know anything about wishes of other customers and so you can only hope that you get what you want. And at last: if you look above, there's a statement (28/Aug/06) from Scott that tells the current situation. That's my opinion. Cheers, Also to add:
I think when JIRA 'took off' as a world class (internal) issue tracker, the clients (like me) loved it and started wanting to use it as a helpdesk too. So, bit by bit it is becoming usable as a helpdesk as well. But this is one of the major issues preventing it from becoming a true player in the helpdesk marketplace, which, in all fairness, JIRA was never really designed for, I am guessing. That's also part of what Hi,
i also have to agree with Kai. What you are doing here guys is not really doing any good. I think the importance of this issue for most of us has already been adressed and i think it is absolutely on the top list of atlassian. Scott said some clear words towards this issue some comments above and i think, that he will keep us updated as soon as there are news, and i believe, that they are really working hard on this and the challenge to balance all user requests at the same time. Lot's of KuDos from me to the whole team for this effort as i think they are doing a good job at this and at the same time having such an open channel of communication as this system. ATLASSIAN, keep up the good work!. Gerd Hi Irene (I'll not "go off topic" again after this)
I agree with you that there's a bit of a "hard line" developing here, and one I am participating in. And it was with no small deliberation that lead me to make my comment. But I don't think it's rude: I think it is representative of the situation. And it's not a situation of our - the client's - creation. It irks me slightly when people complain about how people react to a situation, without giving the same sort of attention as to WHY they're reacting that way. I'm being rude. OK, maybe that's the case. But isn't that just a symptom of the issue, and the issue itself is WHY I'm resorting to being rude? (I hasten to reiterate that I don't believe I actually AM being rude). However I concede this is perhaps not the forum for the types of comment such as my one above, and I invite someone with sufficient privileges to delete my comments. Cheers. I'll add a more definitive comment later, but one thing that I wanted to clear up:
This is unfortunately not true. Every release we fix some of the top issues, and it is really the last 6 months that field level permissions has become #1. The unfortunate part of our 'popular issues' report is that it reports "popular issues that are not yet closed". The ones that have been fixed in recent versions do not show up on the list any more. Here is a link showing the issues that we have fixed, sorted by number of votes (you may need to add 'votes' as a column. I'll raise this as a feature request): (Whilst there may be less votes for those issues - also note that as we have more users of JIRA, the relative number of votes on each issue has risen). In terms of a concrete date - we can't give that. We would like to, but any date we give now would be completely made up, and I would not feel satisfied with it. We are working on this internally (and working towards this with other features). It keeps me up at nights working on a solution that will make everyone happy (and not something that is just 'tacked on'). A solution that you would expect from a commercial product. What can really help us is use-cases. Which fields do you want to hide? From which users? In what circumstances? Do you only want it for certain workflow steps? Information about how you need this feature to be implemented (and specifically, what you do not need implemented) would help us greatly as we map out the solution. I think that you are right to expect a lot from us (and I am glad that you hold us accountable). I also really appreciate those of you who 'stuck up' for us. That is really touching, and everyone here appreciates that (more than you would think). Cheers, Scott,
Thanks for the comments. We are extremely supportive of this model (transparency, etc.) and can understand that you cannot fix 4100 "top issues", as everyone has their own. I've asked someone on our team here to post a more detailed case study and show how he hid a field. A basic use case looks something like this: business user can "request" a feature to be in a certain release (custom field since we needed releases/versions to span our projects), but they cannot "dictate" that it is in a certain release. We do not want them to edit that field. So, they request, and someone who is "accepting" the work can set the release field as necessary for scheduling/planning. Mark We tend to use Jira as an internal issue tracker than a helpdesk, and until recently, had no reason to think about hiding fields, but we now have a very simple "use case" for you (I don't know how to specify these formally I'm afraid).
We have "offshored" a proportion of our support and development teams (mostly to the building next door to my office to be honest). We have a lot of commercially sensitive data, which is fine to share internally, but the management have concerns about some of the data being seen by people outside our organisation. As we populate our test systems with production data, Jira issues sometimes get raised with sensitive data included. We also want to use Jira to track the performance of off-shore teams - at the moment, this is done by a completely separate manual download/spreadsheet process, because we don't want them to have any access to what we're tracking. But what we'd really like to be able to do is track it as part of the issue. In both cases, the ability to completely hide specific custom fields from users (based on group membership) would be ideal. I would guess you'll hear use cases to hide every field. Like Nicolas, I've convinced our company to use JIRA as our only helpdesk. So, I have a number of fields I would like to hide from external users. Notably - assignee. We don't want our clients to know who is working on an issue so they won't call them directly. Even who made a comment or transition on an issue would be helpful to hide (it could show anonymous/unknown if the user did not have rights to see it). We have also opened up some of our development projects (and some of their issues) externally and we would like to add a field like Estimated development cost, and hide that from our external users. It sounds like the field configuration would need an additional "Operations" link called security which allowed the user to multi-select groups (and roles?) with security to view the field. And this would obviously have to carry through to all view/edit screens as well as change history. Fields like commenter may not make it into the first release, but the preceding would be a good start. What do you think?
It is curious that comments have always had this feature, presumably for the same reason Scott's request for use-cases is precisely what is needed here, IMHO. One of the problems with this issue, frankly, is that it represents a completely generalized, non-specific "epic" of requirements. All of the more specific issues that have been raised along the way have all been rolled up into this issue and closed, which I personally believe is a mistake.
Epic's never get completed. Individual stories do. Break it down, break it down! Here's my top five user stories that, if addressed, would give us most of what I need even without full field-level security control. 1/ Prevent external users from being able to set Fix Version. How you implement these in the most expedient fashion, trading off the inevitable engineering desire to generalize a solution to the nth degree vs. make the minimum change required to deliver the specific, narrow, requirements of the user stories is up to you...although various "agile" approaches would advocate the minimum effort today to meet the requirements as stated as rapidly as possible with refactoring for generalization (perhaps) later. Yep,
this definition would work for me. By writing "Prevent external users from being able to see...", this also means the history of the issue ofcourse. I would be perfectly happy when the "features", as defined by Brett were available. ETA:
I was wondering why Mark just didn't use the built-in permission to edit fix-for version, when I realized that he wanted them to view a custom field but not edit it (allowing their own staff to edit it). It looks like there needs to be a matrix of groups and permissions (i.e. a group/role may be able to View: Yes/No, Edit: Yes/No). I could probably design a U.I. in a short time. However I can see how Atlassian wants to get it right before they dive in!
Can't you do this already with permissions? We have customers accessing jira, and we don't want customers to see several informations, such as:
Original Estimate All Also we would like to have two threads of comments, private comment (for internal communication) and public comment (for communication with customers) or possibility to say, when writting comment, what group can see comment (bugzilla have something similar). Like Neal said above, I'm looking for a "matrix". Not necessarily in the UI, but in what it allows one to do.
The biggest part of this, IMHO, is the view permissions. Biggest, both in the sense of need and in the sense of level of complexity to implement. The Edit part can be worked around by using the workflows. This really is a HUGE feature in terms of complexity. I'm sure Atlassian will have to modify a lot of code to get the View permissions feature implemented. Like many in this thread, my company wants to expose our Jira system to our customers, but hide specific fields (just Assignee at the moment). We can already hide the comments, but we don't want to expose the specifics of who is working on which issues. Basically, we don't ever want to expose the Assignee on any screen or report based on the user group or role. I had just about completed an evaluation setup of Jira when I ran into this and was showing it to one of the potential internal users when we ran into this. Unfortunately, it may be a showstopper for us. I can appreciate the difficultly of fixing this - just about any piece of software has certain characteristics that can be pretty difficult to change.
In just about every other aspect, Jira meets or exceeds our needs. Guess I will be watching this issue. Michael - as a workaround, we created pseudo-users "Support Tech 1, etc." so they could not see to whom an issue is assigned. Theoretically, on any given week that could be a different person. By hiding e-mail addresses, they don't know who that is. I allow our developers to log in as their normal username which records comments with their name (although I've also hidden that in the e-mail notification).
Scott,
since you're asking here are a couple of use cases for field level security permissions I don't think there's anything special about it but I hope it helps anyway. Repair issues To avoid potentially embarrassing situations where I am showing a customer a Development issues Another (very similar) case I have is with development issues. I have a Keep up the good work. Tom Hyder Magneti Marelli Racing Ltd. Tel +44 (0)1865 487150 – My real use case:
1. We do software product for business customers (big telcos) who are competitors to each other. For our project management and cost/revenue division we need field "customer". In the same time we have to be sure that customer sees contents of issue, but does not know who are the other customers, who was actual submitter. Current workaround is that we have separate projects for separate customers, and manually duplicate issues to the actual internal product development project. 2. Also Time management/estimate fields should be hidden from the customers, as this number is always smaller than sales persons put to the actual bill (with all overheads, margins etc), so there could be possible misunderstanding. About Jaak Laineste's use case number 1: We have solved this with issue security schemes and user groups in this way:
This does enable us to keep issues from various customers separate from each other while remaining in the same project. However, it does not address keeping selected fields in a single issue from being viewed by various users which is the real scope of this issue. But Jaak's comment brings out that "security" is a complex topic. Jaak probably can not implement the "issue security scheme" approach described here because it is not enough for his environment. Field level security is also required to make it all work together. i would really like to see this feature to be build in too. esp. for the time tracking view settings. I don't want that my external customers my see our timetrack budget and/or logging.....
any idea how soon this can be fulfilled? Also permissions on sub-tasks must be seperated from the Create issue permission.
This is really needed. When this will be fixed?
Atlassian, thanks for the great product We have basically the same requirement. We have internal users (developers) that need to be able to see all fields. We want to allow clients to be able to submit issues, but not be able to set all of the fields. We basically need two different "forms". We want a form that is limited for our clients and we need a form that has all fields for our developers.
we need this at my work - so we can log time estimates but not have them viewable by the clients.
We want to add input to the need for field level permissions. In our situation, we want to add a cc field to a project, but we want to make sure that when a user selects the user picker, only users that have access to that project will be listed in the userlist to pick from. Currently, our cc field is a field we use for any project, so it has global permissions. This creates a huge userlist when you use this cc field on a project that may only have a few users. We'd like the cc field to inherit permissions based on the project or on a group of users who have access to that project.
Please, please, please, please, please start adding some kind of field level security. Even if it's not the be-all and end-all solution, we desperately need to start hiding some fields.
Heck, if you just gave us two levels of security - public and private - with private tied to a "magic group" I'd be happy for now! Deb Gibb - I think your issue is more tied to JRA-7467 than this one.
Hello, since it doesn't look like Atlassian is going implement that feature soon (correct me if I'm wrong, please), how about some workaround:
We plan to build some kind of "filtering Jira-Client" on our website. Roughly it could communicate with our server via intra net using web-services and present only public stuff. Does someone of you know some work already done? Any suggestions? Regards Mike I've come up with a simple approach that I haven't seen anywhere else. You can tweak a single template file per field to control who can edit or read the field. Details are at
http://confluence.atlassian.com/display/JIRAEXT/Using+Templates+to+control+edit+of+an+issue 
~Matt What we would like to see is basically this:
Setting the visibility of every single field to a specific group. In detail we would like to hide these fields from the customer point of view: Custom fields (e.g. the internal status of an Issue) These fields should be removed from:
Abwesenheitsnotiz:
Vielen Dank für Ihre Mitteilung. Momentan bin ich abwesend. Ich bin ab 23.07.2007 wieder für Sie da. Ihre Mail wird nicht automatisch weitergeleitet. Falls Ihr Anliegen vorher Aufmerksamkeit erfordert, wenden Sie sich bitte an +41 41 727 2131 oder support@systransis.ch Notice of absence: Thank very much you for your inquiry. At the moment I am away from my desk and my e-mail. I will be back on 23 Julz 2007. Your e-mail will NOT be forwarded automatically. Should you need to contact someone before this date, please call +41 41 727 2131 or send a message to support@systransis.ch Is this issue fixed in any of the JIRA versions? We need few fields not to be editable after a certain workflow actions, or fields editable by a group of users once they are entered.
Is there a way to solve this problem? Abwesenheitsnotiz:
Vielen Dank für Ihre Mitteilung. Momentan bin ich abwesend. Ich bin ab 23.07.2007 wieder für Sie da. Ihre Mail wird nicht automatisch weitergeleitet. Falls Ihr Anliegen vorher Aufmerksamkeit erfordert, wenden Sie sich bitte an +41 41 727 2131 oder support@systransis.ch Notice of absence: Thank very much you for your inquiry. At the moment I am away from my desk and my e-mail. I will be back on 23 Julz 2007. Your e-mail will NOT be forwarded automatically. Should you need to contact someone before this date, please call +41 41 727 2131 or send a message to support@systransis.ch Atlassian would have marked it as fixed if it had been completed. There are a number of workarounds in the comments on this issue though
We switched to JIRA from TestTrack but some features of TT I miss, one of them field permissions.
I like it was implemented in TestTrack - field permissions (R/W, R/O, Hidden) configurable for each user group. This is really needed. This is exactly what we need.
Please tell me in which release this will be fixed. We are in process of adopting JIRA. It´s a great tool. However, what we REALLY need is a way to hide the worklog from users view.
We dont want customers to see our time tracking. Simply hiding the "Estimated Time" row and the "Worklog" tab should be enough (also, the "All" tabs). Is that really hard ? Any tips on that ??? why not just use screens and have screens by users/groups/roles
Thank you for your note. Please be aware that I will not retrieve e-mails from Tuesday, 28 August 2007 AM until Wednesday, 5 September 2007 AM.
Should your message require urgent attention, please contact: carl.courtie@hansard.com In all other circumstances your message will remain queued for my attention for when I next sign on. Luke Davies >why not just use screens and have screens by users/groups/roles
Because you can't associate screens by user/group/role. Even if you could, it could get very complex very quickly. Field level security is a much simpler approach, even though it's quite complex to implement. >why not just use screens and have screens by users/groups/roles
This would not be safe at all - smarter users could still select your top secret field in the issue browser (by customizing it). my idea was that it might be easier to implement.
We need this feature as well. We want to set up a custom field for all issues in our system, but some of the projects we conduct are co-development projects with external customers, and we don't want them to know that this field even exists. No change history, no notifications, no create/view/edit, no searching, no filters, no nothing.
We also need this feature to be available on Jira particularly to hide sensitive information and also a segregation of access (read/write) to a particular customised fields to control input. For example within a IT defect tracking scenario, you might want end-user to enter issue but not necessary being able to change the code release date.....
This seems like quite a fundamental function for a full fledge issue tracking application. I'm supprise that this is missing from Jira! This is a feature that is at the top of our list in terms of need. As mentioned by many of the previous posts, our immediate need is to limit who can see work log and time tracking information.
True field-level security, however, would mean that a lot of the configuration that we now must do to try to hide certain things from the client would become greatly simplified - or at least more intuitive than the current mechanism of combining permissions, issue types, screens, and all of their respective schemes and sub-schemes in order to achieve an adequate (but less than ideal) solution. Although Jira has already proven to be an excellent purchase for us we, regretfully, will not likely be using Jira in a client-facing capacity until we are able to get the time tracking issue under control. It would be helpful to know if/when this feature may be considered for release as it would help in our decision as to whether we need to consider developing a solution in-house. We are waiting (for Godot
 ) too ... although we are using time-tracking, it is confusing for our customers what is means and therefor i would like to hide the information for them, cause it is not the information they need! We are urgently waiting on this to be implemented. Can someone from Atlassian tell us when this will be done???
Dear Atlassian Team / Dear Atlassian Product Manager
433 Votes, 265 Watchers (i.e. potentially 265 companies), 100s of comments. YOUR CUSTOMERS really NEED this functionality. Please "listen" carefully and consider the implementation asap - the issue has been reported in May 2003! Your message
To: "heather.daymon@configuresoft.com" <heather.daymon@configuresoft.com> did not reach the following recipient(s): The e-mail account does not exist at the organization this message >(i.e. potentially 265 companies)
264, we've got two people watching. This issue really is completely stopping wider adoption of Jira here though - we have five Jira servers, but would have had 9 by now if this had been implemented. Actually, 7 of the top 10 "most popular" items are blockers, to the point where we're starting to look at other tools to replace Jira, but this is the biggest. Your message
To: "heather.daymon@configuresoft.com" <heather.daymon@configuresoft.com> did not reach the following recipient(s): The e-mail account does not exist at the organization this message What is the difficulty on implementing this ? It should be only a flag to show or not the time tracking information !
It's not just about time tracking - it's all the fields in Jira. We (the Jira community, not just my site) want to be able to control access to almost every field built into Jira and any custom fields we add. We don't actually use timetracking at all, but we are keen on field security.
--> It's not just about time tracking - it's all the fields in Jira. We (the Jira community, not just my site) want to be able to control access to almost every field built into Jira and any custom fields we add. We don't actually use timetracking at all, but we are keen on field security.
Indeed
100% agreed We all wonder if/when Atlassian will seriously comment on this and commit the release date for this functionality in the nearest future. Jira is such a nice product, but the lack of this functionality is almost a k.o. criteria for an enterprise system! We are new adopters of JIRA in our company and this is THE first feature we were missing after few days of configuration and use.
We are currently stuck in an internal use due to this. We definitely cannot open our JIRA server to our clients as long as fields and other sensitive internal informations cannot be hidden to our clients. So indeed, any comment from Atlassian on this issue would be appreciated... Actually we are NOT using time tracking, because we can't hide it to our customers.
Atlassian, we are too, (and still) very interested in this feature, like all the other users who commented here. We originally wanted to use JIRA to keep track of issue enhancement with our IT Vendors and internal IT dev team but found the limitation of field (custom or default) permission too limiting and decided recently to move off JIRA - eventhough we brought the software. As a result, we are currently evaluating other packages on the market.
Field permissionning is a basic functionality one would expect an enterprise issue tracking application to have. I don't think I need to illustrade how this can be used in business scenario. I'm really suprise that JIRA team failed to act on this. Dissappointing... Until this issue is being address, this application is on the shelve. Atlassian has updated this issue. Please refer to the description field for information
Oh dear. Before you get the well-deserved opprobrium, how about doing a better job of summarizing the workarounds than a a few links?
You could specify when each approach is useful, e.g. a field should be read-only for some people, a field should be invisible for some people, etc. OK. I hear you. I'm sure a flood will come to this issue. Here's my question:
I renewed JIRA based on the delivery of this issue. It is the only issue I considered worth upgrading and renewing for since 3.6.5. I even spoke directly with Scott about this, explaining that without a commitment to this issue, we would not renew our support license. "Let's bury this under the carpet and see if this goes away" approach. It's easy to look the other way and find reasons not to do this. Understand if this something trivial but this is a core functionality for an issue tracking application.
If Jira as an issue tracking application wanted to be considered as an enterprise solution, then step up. Ultimately this response tell me all I need to know. Good luck. As an enterprise JIRA customer, I am extremely disappointed that this issue will not be addressed. I cannot believe this issue was created in February of 2003 and received this much attention from voters and watchers only to be indefinitely deferred because of architecture constraints. I think it would have been just as easy for Atlassian to triage this issue 4.5 years ago with the same result.
This is the first time I have been disappointed with Atlassian's openness/process/roadmap/etc. I would like Atlassian to redefine to us customers what JIRA is trying to become so that we can make an educated decision as to whether it will truly work in our production environments going forward. I think a step in the right direction would be having visibility into a longer term roadmap for JIRA. I think just the big features would suffice. I appreciate any feedback. Thanks, i can find myself in the arguments to not act on this issue, however i would like to see some related calles being re-opened again. one of the mayor arguments that this issue has so many votes is that this issue would give jira customers the ability to hide time-tracking fields..... That will not be a huge effort to build i guess!
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.
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...).
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 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... This is extremely disappointing !
Disregarding customers needs this way is completely incredible. 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 ! 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. The thing is... does this reaction from Atlassian actually surprise anyone, any more?
It took four and a half years to say - Won't Fix
Sad  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 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 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. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
New Feature
Resolved
Critical
Field level security permissions
. Just wondering - why this feature was added for comment... was it always in place? And, in recent releases, hiding original values of comments in the change history has also been addressed.
I would like to be able to decide which fields are viewable by which users and witch are editable. E.g. I do not want my customer to see my time estimate nor do I want anybody to set it during creation of an issue.