|
This would save a lot of time and effort for me. The business units I currently support through Jira would love to be able to do their own User Administration..
I do have a few comments about this: I hope that this is configurable per group permissions. (much the same way a Permissions scheme is used) I also hope that anything that one of these "delegated" admins create can be turned into a global item easily. Regardin to: 1) Add users (though this could be a seperate user-administrator)
For this in my opinion the most general solution would be to implement something what is common in most RDBMS systems. Unfortunately this won't be done for 3.1.
When will this be done?
Lot of votes  As I commented on the user list:
This is a very complicated change and there are a lot of issues in regards to shared schemes. Sorry to disappoint. Cheers, This issue is definitively one of the most wanted features in our company. Each project manager shall have the rights to administer "his" users as they may come and go. The global administrator for the Jira instance has other tasks to do, such as backups, create projects etc. Imagine what a relief for the Jira administrator it might be that he does not have to add 10/20/50 users to a new project... He can simply delegate this task to the project manager...
When could we expect an update on this? Thanks. Andreas,
Unfortunately this has still not been scheduled so I still can't give you even a guess as to when this will be implemented. I can't really say anymore than I said in my comment above. Cheers, When implemented, we should consider allowing a project admin to define new issue types in their project (now we have Issue type schemes
 ). It seems to me that the complexity of this issue is tied to the boil the ocean approach. It makes sense to decompose this issue into the most common cases.
We need the ability to entitle someone to add and remove users from a project (that is not a jira-admin). This seems to be the most common subcomponent of this request. Would it get some more traction if we decoupled it from the broader request above? For me, yes, I think we only need a relatively simple approach.
Our users can create accounts for themselves (i.e. jira-user group All we really need is item 3 below - if our "project" level admins could Jeff and Nicolas - I installed a plug-in
that does exactly that (for project lead). One of the other users wrote it, and it works great. Project Adminstrators should have functionality to create users, change user group association and also create or change issue types, issue screens for their project. This will reduce lot of work load for jira administrator.
When do you think this kind of functionality will be available in jira ? regards, Any update or this is still TBD ?
Hi Rajneel,
Unfortunately, at the moment, I do not have an ETA for this issue. Thanks, Some more comments from an evaluator:
Full administration rights for a project administrator should include: modification of the JIRA instance adding plugins, creating workflows, issues for the project, restarting the instance without interfering with other projects, adding subversion-access without having to restart JIRA for all projects, adding new users to a group or any sort of change in the user permissions. The project administrator rights within JIRA do not allow such things. This is very nearly a blocker for our use of the product. It is vital to get a level of control between JIRA-admin and user.
More substantively, looking at the list of things that this administrator is being given to be able to do, it appears that we are allowing the project admin to create new projects, and presumably project admins. I have to disagree with this, the required functionality does not recurse. If the JIRA-admin has to create projects and project administrators, that is acceptable and provides the necessary limitations. Project admins would have responsibilities for their own users, projects, groups and all the rest. I suspect that accepting this limit would make changes easier to accomplish and thus sooner done. respectfully BJ - have you tried the plug-in in the meantime?
http://jira.atlassian.com/browse/JRA-3156#action_50564 Neal,
the main problem with the plugin for us is, that the project admin cannot add a new user, the user can only made assignable, and only when he/she already exists... Please consider this feature... It does not seem to involve that much work, does it?
Regards I quite like the plugin myself, it fixes half of the problem I have with the user admin.
1) I've been encouraging my users to add their own accounts using the sign-up link on the front end, so I don't need to worry about user creation. In fact, I'd rather people signed up themselves all the time, rather than allow the project admins do it for them! 2) This plugin gives my project admins the ability to add their "developers" to their projects. 3) The only thing that is missing for us is the ability to add "issue creators" to the projects as well - we have many projects with distinct "analyst" and "developer" groups - the analysts raise the issues, but can't work on them, and the developers work on the issues but can't raise new ones. If I ever get any time, I was hoping to look at the code for the plugin and see if I could tweak it. 4) Delete is a bit of a sticky issue - I'd actually like to limit it to the core Administrators, but I can see why a project-admin might want to remove a user from their project (we don't need this, but I'd say it would be important on a lot of sites). I'd want to do this the same way - assignable-admin allows a project-admin to remove a user from any group that would allow them to add/change/view the project. I don't know if any of that makes much sense, but I thought I'd add my 2p worth. Nic Thanks Neal... I was not aware of the existence of the plug-in. I have only JUST been pointed here in response to a question I asked in pre-sales.
If I understand the limitations of the plug-in correctly it would probably not do what we would want it to do. We want to keep project admins away from global settings, other projects and other project's personnel. This is, in the main, achievable in Bugzilla simply by assigning each user singular and explicit privileges. There are limits to this flexibility at the group level and Bugzilla has any number of problems for us... the customer asked for workflow customization (ouch!) but I can create projects and project groups and project administrators who mostly have exactly the privileges required and nothing more. Not sure I agree with "deleting" a user. The nature of what we're doing makes the deletion of the person who did something to a project fraught with problems of historical revisionism. Removing them from the project of course, is perfectly reasonable, denying them access to anything including login, is reasonable. Deletion? ?? I wouldn't. respectfully Interesting. This issue is number 2 on the open issues "hit parade" in terms of votes. - respectfully
BJ
I do this by creating groups specifically for this purpose. For example, one project has a group set up just to record who is to be notified about new issues. Rather than make the project admin a jira admin so they can manage notification schemes, I simply set up the notification scheme to include a group, and the assignable admin plugin lets them manage that group so they can effectively manage notifications without my involvement. Hi All,
Kaamelot Myrddin Rgds Guys,
Just an update - I think that much of the project roles functionality in 3.7 will help people here. When 3.7 comes out - can you see if this helps at all? Hi,
I think the project roles functionality in 3.7 is a great feature - I'd really like to use it. But in my opinion it would have been better to implement it with a separate "administrate project users"-permission, not merged into the "administer project" permission. We have some really sensible projects here where I can't allow the project administrators to do the user management (because they can add any user from the user base). But I need the project administrators to manage the versions and the components. I don't know how other JIRA administrators think about that... I just hope you understand my point of view. (There's already a an improvement request: http://jira.atlassian.com/browse/JRA-11806 Cheers, Irene Hi,
In the "enterprise" version (using 3.7.3 at the moment), everything should be project group specific. By this I mean:
The project group specific administrator for project group A should not see the projects specific priorities, issue types, workflows, screens, schemes, custom fields of project group B, or administration becomes a mess. In a big organization it's not conceivable that hundreds of projects all have their custom workflows, fields etc... in the same installation, and only one administrator maintains all this. On the other hand if you give admin rights to one person in every project group, how long does it take before your default screens and schemes and workflows are all messed up? The "enterprise" edition only applies to very small enterprises, and should probably be called "super-professional" or something. I understand this creates problems at least in the "find issues" page (like what priorities, issue types, resolutions are displayed there), but I don't think you need cross project group searches anyway, not in big companies at least. So a project group specific search page (where you first select the project group on one page and fill in the rest of the criterias on the next) would probably be more adequate. Maybe you don't even want your users to be able to search in other project groups, so you could restrict it. Anyway, just a few ideas...
In our company, we have roughly 100 projects, 40 teams, most of them need autonomy--project administrator from the team. However, we still need cross-project filters like "all issues assigned to this developer/this team", including issues from other teams. What I believe is needed effectively a administration permissions scheme.
Whereby all administration tasks have associated permissions (on a global and per project basis) which can thus be effectively delegated. Instead of the current situation where you have to give a user JIRA "root" access in order to create / modify assign schemes to allow them to customize a project. Having administration permissions allows this to be customized as required. Effectively we need to be able to have project administrators who have complete control over a project (and its schemes) and leave them to manage their projects without the ability to stuff up an entire instance by making global changes - thereby having responsibility over their own project, if they stuff it up its their own problem. Another issue which I read mentioned scheme level permission, such that a scheme has an owner / permissions thus dictating who is allowed to make changes to it. By creating an administration permissions scheme and being able to specifically delegate administration duties (through permissions) will provide the best and most customizable solution. The "boil the ocean" comment was spot on. We might try to decompose this into smaller stories.
Nicholas Wong's comment struck me as correct, or very close--this is how I envision the server-admin controls. We have 70,000 potential users across multiple colleges and departmental units. All of these users already has a central intranet identifier. These are the stories I WANT to be able to tell about our installation:
Hopefully this helps. I think Martti von Hertzen's comment is exactly right – the way the permissions are structured, the "enterprise" edition only applies to very small enterprises. For an organization of any size, multiple installations are required. Otherwise, you either overburden the administrator and reduce the efficiency of work for project managers, or you give too many people the ability to change the core configuration settings. It seems obvious that the role of administering the JIRA instance itself should be distinct from the role of creating and administering projects within the instance. Why is it necessary to grant someone the right to change the system-wide email server, or the system look and feel, or the General Configuration settings, just because we want them to have the ability to create their own projects? There are several different needs expressed here, but I think the original description best captures what we are looking for. Basically a Project Administrator as opposed to a JIRA Administrator. This issue has been open for a while; the description says version 2.5.3 and we're using 3.9.3 Enterprise. Any plans to implement this functionality? Absolutely correct.
NOW.... is there any movement on this? This issue seems to have high votes How much longer do I need to keep my cool? Kveðja / With regards Axel Valdemar Gunnlaugsson Sími / Tel. +354 550 7953 Ármúli 25 ? 108 Reykjavík ? Iceland ? http://www.siminn.is Síminn auðgar lífið "Steven Webb (JIRA)" <jira@atlassian.com> To Subject Steven Webb commented on JRA-3156: I think Martti von Hertzen's comment is exactly right – the way the It seems obvious that the role of administering the JIRA instance itself There are several different needs expressed here, but I think the original This issue has been open for a while; the description says version 2.5.3 essentially "root" in Jira. – Ábyrgð þín varðandi tölvupóst / Your E-mail responsibilities: Hi,
We do realise that this feature is important and are hoping to split it into smaller tasks and attach each one. However, at the moment this work is not scheduled, and therefore, unfortunately, I do not have an implementation date for this feature. Cheers, For heaven's sakes! You have 255 votes and 109 watchers. How do you prioritize your work schedule?
I will be on vacation from 09/29 - 10/9. If you have any web application issues, please contact distapps@tufts.edu.
Bill S. Atlassian have this to say about prioritisation - http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements
- the popularity of an issue is only one factor they consider.
I understand your frustration though - we're still using 3.6, because there hasn't been a single improvement since then that is of much use to us. Some nice-to-have stuff, but nothing it's worth upgrading for (new installs yes, but not upgrades to existing systems) Yet there are 5 items in the top 10 where any one of them would prompt us to upgrade. I can't understand that the "ENTERPRISE" issue tracker, JIRA, doesn't implement it, yet.
This feature should be implemented ASAP. I really want to get it. "Me too" - This would be incredibly useful.
This is the number-one most requested feature in our installation of JIRA. JIRA is used across 15 departments within our enterprise, only one of which has any idea what to do with any of the server or installation related items, or that we want to have access to them.
Users are clamoring for more projects to track our approx 200 seperate internal applications, but there's no way I can manage that with the current JIRA feature set. We find the single level of components very limiting.. This enhancements request along with subcomponents and/or subprojects would fit the bill. Voted for this one!
The functionality of a Project Group Administrator would be of great use for us, too. For us it's also important, that the project group administrator is allowed to see the projects of his/her own group only. Hope for a soon implementation of this feature
This feature is an absolute must have for any company that lives and work in the fast paced financial world. Is there an ETA on this yet?
This is a enterprise must have. We need it. ETA please!
This is a critical to allow the assignment of JIRA administration functions to be delegated to project administrators to have manage the configuration restricted to a project without impacting other projects
Any updates on this? This is the feature most requested in the company I work for.
Ultimately, the absence of this feature killed the project at the
University of Minnesota. Without this feature the product won't scale for our institution. I no longer use JIRA at the U. We got a site license for Copper instead, and that's the officially supported product on our campus. – Due to the lack of this feature, the National Center for Atmospheric Research is considering running separate JIRA instances for each of our labs. Obviously non-ideal and it's close to being a showstopper for us. We really need to be able to delegate all the JIRA-administrator capabilities to a project admin for just the schemes associated with their project.
Yes, this feature is also for us a strong requirement. Any news on that?
I agree. We have an enterprise version of JIRA and one of our biggest show stoppers from everybody in our company to start using JIRA is this lack of ability to have true Project Administrators who can administer all aspects of their projects without impacting other projects.
A project administrator can hardly qualify that title if he can not administrate the most important aspect of a project - the people involved. To that end, allowing project admin to assign project specific roles to user should be a must-have feature. This option is better than adding a separte layer of administration because of simplicity.
I think, that Atlassian isn't really interested in implementing this feature.
Fully implemented it would allow to run all projects on one central JIRA instance without tapping into an administrative nightmare. And thus it would effectivly allow to run a company wide JIRA installation buying only one enterprise license key instead of dozens.... The following solution would also fullfill our needs.
In August I was told by the Jira project lead their hope is for Q1/09 for some kind of administration feature improvements.
So far I cannot see any prove of hope for Q1/09, issue is still not scheduled.
Atlassian is planning SOW for JIRA 4.0, can see many technical issues lodged by Atlassian staff and nothing from high voted customer requests yet. The Administer Projects permission is far too monolithic. We should with our permission schemes be able to determine who can add users, add/edit components and versions. Exposing user management to those who should only have access to components and versions violates our security model and this issue should be addressed.
This feature is a must-have. We need the ability to give certain users permission to "manage users" but nothing more.
Nicholas Wong's comment (Posted 22 months ago) is dead on. Global permissions need to be much more robust. Any product that is advertised as "Enterprise" level should always have the ability to fully manage permissions throughout the entire system. Jira is already extremely robust in certain aspects which is exactly what makes it such a great product, but when you run into a situation like this where you "hit a wall" you hit it hard. Because you simply cannot do what you need to without modifying the source. As I say in all my comments, Jira is without doubt an incredible product. But, what's wrong with adding some improvements to make it even better? I only can confirm with what Eric Rutherford said before. He explains exactly the dilemma that we have. We don't want our project admins to change project role memberships. They only should be able to edit components and versions.
A more specific way of giving permissions to project admins is needed. Splitting "Administer Project" into three permissions "Edit Project Role Memberships", "Edit Project Components" and "Edit Project Version" would help us a lot. That's why I voted for this issue. Are there any plans of improving permissions (especially admin permissions) in the near future? This is a very and necessary improvement for a corporate world. I work for a bank and we do have a security officer which manages all access throughout the bank. He must have it centralized and JIRA was part of an audit report being an application not able to descentralize the user administration which is a bog deal for bank compliance.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Required: Project Group Administrator
-) alter contents of project specific custom fields
I really like this idea and would suggest it be enhanced to allow for role specific global administration - so that you could have a role that would allow for the editing of global custom field values and nothing else. Most custom fields we use are global but only appear in a few projects.
Additional 'admin roles' could include:
-workflow admin - alter workflow transitions, states, etc. This would require the ability to disable the workflow across all projects that are using it
-Project issue field scheme admin
If these were just added to the project admin role such that the admin could only modify workflow/field layouts associated with their project - the user could assign a new workflow, alter it, then change back to their original workflow, circumventing security. However, the ability would be nice.