Feature #4427

Create a new type of role for not project specific maintenance

Added by Holger Just almost 8 years ago. Updated over 2 years ago.

Status:NewStart date:2009-12-16
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Permissions and roles
Target version:-
Resolution:

Description

The current role / permission concept is based on the assumption that everything of the daily work is done inside of projects. While this is true most of the time, there are more and more cases where things are done outside the scope of a project.

One example of this is the new permission to create projects as a non-admin user (#2963). This is allowed, if a user has that right in at least one project (checked by performing a global permission check). If she has that permission she can create projects anywhere in the project tree (at least if I understood the feature correctly).

However, this is not what I would expect from that permission. I expected, that a user with that permission were able to create a subproject on the project with that permission only. That permission being consequently project specific. The opportunity to create projects anywhere in the project tree is something that I would expect from an admin user only.

Another example is the creation of trackers and issue states and its management (workflows et al.), or the creation of custom fields. This is currently only possible to admin users.

In large installations which are used by many different organizational units of a company, this can lead to a large indirection, as it is not feasible to have a huge amount of real admins with the ability to look in every project. So requests to have certain features added have to be directed to one of the few admin users.

To solve this, I propose an additional type of role. These new roles can be assigned to a user but no project. They should allow to grant a user certain global rights, like the creation of global projects, custom fields, new trackers, ... The goal is to prevent the misusage of global permission checks as done by he "create project" permission check in the ProjectsController

I think, these new roles could be fairly easily patched into the existing permission model and providing similar functionality as the global check. But the permissions / roles are explicitly declared by the user, who can then better understand the consequences of certain permissions.


Related issues

Related to Redmine - Defect #4431: Non-admin user cannot create project :for revision 3174 Closed 2009-12-17
Related to Redmine - Defect #6728: how to assign global rights? Closed 2010-10-22
Related to Redmine - Feature #6670: Admin rights should not override rights given through roles New 2010-10-14
Duplicated by Redmine - Feature #6800: howto assign global rights Closed 2010-11-02

History

#1 Updated by Andrea Campi almost 8 years ago

I'll second that.
In addition to the examples provided by Holger, I would like to see a "user manager" role that would allow a user (IT staff) to create new users and assign them to groups. The rationale is that offloading some "grunt work" without giving my IT staff access to all projects, since some of them contain confidential information.

#2 Updated by Jean-Philippe Lang almost 8 years ago

I agree that it would be a real improvement.

For the "create project" example, we could distinguish "create project" and "create subproject" permissions.
The first one would let the user create a root project, the second permission would only allow creation of subprojects inside his projects.

#3 Updated by Daniel Schuba about 7 years ago

+1 see also #6670

#4 Updated by Albert Rosenfield almost 7 years ago

+1 see also #6800 (same feature, different solution proposal)

#5 Updated by Matthias Michelsburg almost 7 years ago

+1 a special role for user management would be great

#6 Updated by Joe Junior almost 7 years ago

+1 as a new user it was the first "flaw" I noticed. I had to create a fake project so that I could give permission to create projects without giving Admin powers (which shouldn't be treated lightly). I'm sure there are other powers that could be useful to hand to a non admin user.

#7 Updated by Zer Guz over 2 years ago

+1. I also think that some "global" permissions (such as "create project") have to be assigned (by admin) per user, not per projects.

Also the way "create projects" is currently granted (as a per project permission) has a security problem: any who has permission to specify members in any of the projects, can grant "create project" to himself or to anybody else.

Also available in: Atom PDF