Feature #4049: Permission management on a per project basis - Redmine

Actions

Copy link

Feature #4049

closed

Permission management on a per project basis

Added by G N over 14 years ago. Updated about 11 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Category:

Permissions and roles

Target version:

Start date:

2009-10-18

Due date:

% Done:

Estimated time:

Resolution:

Duplicate

Description

Currently, it is impossible to set permissions for a role on a per project basis.

For example, assuming that we have two projects, A & B, it is impossible to make the "_documents_" and "_repository_" modules publicly available on project A, while at the same time keeping them private (granting access only to Managers and Developers) on project B.

I think that the ability to (at least) manage the "view_*" or "browse_*" permissions per project would be a natural requirement for a multi-project management software.

Unfortunately, my knowledge of Ruby is zero (at the moment), so I cannot provide any patches. But I think that implementing this feature would not be complex, as all the functionality exists.

As a quick suggestion I would say that a new project-related permission, "Manage Permissions", should be available to enable/disable for the "Manager" role. And then, a "permissions" tab could exist in the project administration area, where the manager would be able to set permissions specifically for the project he manages.

I hope my suggestion is clear enough and I feel sorry for not being able to contribute any code.

Thanks in advance.

Related issues

Actions

Copy link

Updated by G N over 14 years ago

I've seen several similar feature requests. I am sorry for adding another one.

Now, regarding the issue, after giving it a second thought, I conclude that by giving the ability to project managers to determine whether a module would be available to non-members or not would be a feature that would resolve most of the situations where a team needs a part of its project space being private to project members only. Such a feature would serve as a small, but highly effective, per-project permission override.

For example, at the Project->Settings->Modules tab, the project manager could have the option to deny access to each module for non-members.

I believe that this could be implemented easily. Also, I think most feature requests about being able to set permissions on a per-project basis would be covered. But, of course, other special needs cannot be covered by such a solution.

Actions

Copy link

Updated by Beat about 14 years ago

Specially, for:

Public project
with private SVN repository

It would be very useful to have project-specific settings for the system-roles (non member, and anonymous/public).

While one could create specific roles with specific permissions just for one project, those system-roles can't be duplicated and assigned for specific roles.

So there is no work-around for allowing SVN access to non-members and public for all projects, but not allow SVN access (view and changesets) to project members only in specific projects.

That feature would greatly help in not-yet first-released open-source projects and in collaborative commercial projects.

Please email me if we can help co-sponsor that feature.

Actions

Copy link

Updated by Felix Schäfer about 14 years ago

Well, we leverage the project nesting feature to work around that, and create say a project project1 and subproject called project1-private, the first being public, the second private. That way, we can have whatever we want either private or public, depending on the need.

Actions

Copy link