|
Sort Order:
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. Our team would also need this feature. 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. 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. 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 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 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. 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) 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, 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, 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: 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 ~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. 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. This is exactly what we need. 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. 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 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. 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? 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. 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 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. 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) 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. In my opinion, another company has paid to Atlassian some quite good money for not implementing this. Very disappointing. "In my opinion, another company has paid to Atlassian some quite good money for not implementing this. 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. 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... 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 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.
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.
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: > > 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. 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. 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? I'm really disappointed about this "solution" ! 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 Hi, I have updated the workaround instructions: 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, 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.
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. 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:
regards, 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
It would probably still leave timetracking, worklog, svn/cvs and others fields like this visible to all, but it's a workaround... 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. Olivier 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: Question2: Another Question? 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?"
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... > 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? 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. 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. 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 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:
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. 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? Yes, I've managed this as well.
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. Aleksei, 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 To have the ability to Resolve or Reopen an issue separated from assigning a Fix Version, you can use a custom workflow. Compare You can also separate "resolving an issue" and "setting the fix version" into two separate actions:
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. 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. 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 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 Hi. 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, 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 I think this would be a great feature too. I'd like to see this added to JIRA as well. It's a real shame that this isn't in the product today. -Ray 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. /**
Sure, patches and source code would be great! Steps: We're using JIRA 3.10.2. Samuel, this is wonderful, thanks for sharing !! Looking at your installation steps, I can see that your are modifying CreateIssue and EditIssue. 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). The requirement is to prevent some users to see some fields, everywhere it is possible to do so. I bet you can make these changes using a few files compiled in external-source and then not have to rebuild JIRA ~Matt dito to the former comments Now it is May 09 from Oct 07 thats >= 18 month ... and? 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, 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 Hello, 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 ? My Jira version is 3.13.5 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, There is a third party plugin Behaviours Plugin 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 Please try this and let me know if there are any issues. Thanks Abwesenheitsnotiz: Vielen Dank für Ihre Mitteilung. Momentan bin ich abwesend und habe keinen Zugriff auf meine mailbox. Ich bin ab Montag 15.02.2010 wieder für Sie da. Falls Ihr Anliegen vorher Aufmerksamkeit erfordert, wenden Sie sich bitte an +41 41 727 21 31 oder support@systransis.ch ------------------------------------------------------------------------------------ Thank you very much for your inquiry. At the moment I am away from my desk and my e-mail. I will be back on 15 February 2010. If your issues needs attention before this date, then please call +41 41 727 21 31 or send a message to support@systransis.ch ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
New Feature
Resolved
Critical
Field level security permissions
). 
Keep up the good work Atlassian!
. 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.
The reporter should probably have described this issue a little better, but it seems like something that I am seeking to.
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.