|
History
| Log In
|
|
|
|
The Apache guys would definitely benefit from this. Each project needs their share of <project>-developers members, and only the global JIRA admin can currently assign people to this group.
I feel each project administrator should have rights to add or remove users into his project groups. So the steps will be as follows:
a. Any user who needs to generate a username/password can get it from the homepage which it adds him to the jira-user group b. The project administrator can then add/remove him to/from his group so as to give/remove permissions. With this setup jira-adminstrator do not have to take care of creating new users and adding him to a group. He will only do a global configuration. To protect data privacy and many huge companies have a special department for user management this permission should be implemented soon.
In my opinion the most general solution would be to implement something what is common in RDBMS systems.
An option could be set for each permission for a user (or a group) which could indicate that this user/member of this group can give this permission to others. I agree - we should be able to give a set of users the permission to administer other user accounts (create, edit, delete, grant permissions, etc.) without having the ultimate JIRA administrator's permission. This group would be dedicated to the administration of users. This individual or set of users could have the JIRA administrator's permission but necessarially have to...ultimately, with this new feature you'd have the ability to deligate this task to someone else.
In our instance, we have 4-5 JIRA administrators (manage different groups in the same instance of JIRA) and one group that owns the JIRA instance. The group that owns the JIRA instance wants to manage any "administrative task" (i.e. custom fields, new project, etc.) by removing the "admin permission" from all administrators and forcing them to submit change requests to the owning group. The owning group can then approve and schedule the change requests and grant the administrator permission to the individuals so they can do the work in the production environment. With this process, we would be putting too much overhead for "user maintanence" requests that come in...each administrator should be able to add/modify users in production without having to request "administrator rights". This new feature request would greatly help in this effort...ultimately, we can hand off the user administration to a designated person. Compartmentalised user management is becoming a critical requirement for the system I work on. A case in point is my own permissions level to the Jira system I use. I don't even work for the company who has the Jira installation, yet I am the support manager for a channel partner selling their software. I need (NEED) to be able to manage users, which means I need to be an administrator of the entire installation, as far as I can tell. This is not satisfactory in an Enterprise-level application.
Cheers. It is becoming critical for project Admin people to have user management and/or group-management rights. We, the Admin people, manage multiple projects in one JIRA instances and end up having a lot of request just for adding or removing one or two users from different projects and at the other hands we can't give the adming rights to project admin people also because that exposes the different projects . It's good to have a feature where you can differentiate between super admin ( like current jira-administration group) and admin group ( having user managment and group-managment rights).
This feature is sort of must feature and now realized and discussed in team meeting as one of big drawback of JIRA. Hi All,
Kaamelot Myrddin Rgds I currently have th following requirements which do not appear to be supported by JIRA:
The only way to allow a user to do this today is to add them to the administrators group which gives them access to change everything. Though this might be a challenge, this is one area of Jira that is decidedly NOT enterprise. If I have to grant admin access to the entire system, to allow a user to place other users into a project role, it exposes my system too much. Put my vote down +1 for improving this, and allowing more granularity.
Here is my scenario, specifically: I have email importing set up in Jira 3.7 Pro, so that users get created, and this is over multiple POP accounts each for a separate project (and separate company). Since I want to keep things secure, in that company A's users should not see B's projects, I have set global permissions and project roles like this: Global perm - users - only has "jira-users" group. When the mail service creates a user in this way, it grants the new user "jira-users" status, but that group has no rights anywhere, except to basically log in. The caveat being, they have no rights, so the initial issue that created their account, will "bounce". I set the bounce address to a distribution list / alias, which goes to admins who can fix the problem, seeing who is emailing in. To give the user access to the appropriate project, they are next granted the appropriate project role membership, and now when they log in, they can see their own company's project only. This is a bit of a pain because a full Jira admin has to do it, but, is a necessary evil for us, since we want our security to be solid. I would like to be able to have the granularity to give certain users, such as those with "admin project", the ability to add users to the users project role. Thanks very much in advance for your kind support. Regards, What is this? A duplicate and crossing out the original, which means that all those who were interested and voted for the original have to come back and change things so that the issue becomes most important to fix again? This is simple enough and clear enough. Project level user administration. Apparently this is a design issue that goes deep enough to make it hard to do... but in Bugzilla it is a tick-box. JIRA has to do it or CANNOT be regarded as an Enterprise system.
BJ Chippindale > I currently have the following requirements which do not appear to be supported by JIRA:
I agree completely with Brian Compton. What we need in our University-wide installation is the ability to permit our 70,000+ users, dozens of collegiate subdivisions and their departmental sub-subdivisions to self-organize. This means allowing people who can authenticate on our central auth hub the ability to create their own projects and project groups, manage their own users and permissions only within those projects and groups, and deny them the ability to read or change the configuration of projects and groups that lie outside the scope of their access. It's vital, and ultimately as BJ says, "it CANNOT be regarded as an Enterprise system" until this is possible. Adding project roles does not really assist me, because project teams cannot share filters to roles in a project, but only to groups. And since project admins cannot create groups unless they're system admins, it creates a large amount of pressure on our campus support team (me). We're not able to roll JIRA out as a fully open campus-wide service until JIRA can support this functionality. I need a permisison that will allow a user to simoply view configuraion like permission schemes, gtoups etc. without the ability to update them.
We also need to be able to allow an IT department to manage user access without giving them JIRA Administrator access
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Create 'User Management' permission
E.g.
Can they see all user or only user with the same permissions as them?
Should they be able to add users to groups they are not in (probably not)?
Needs more thought