|
History
| Log In
|
|
|
|
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.
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, 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... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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.