Feature #4049
Permission management on a per project basis
| Status: | Closed | Start date: | 2009-10-18 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | Permissions and roles | |||
| Target version: | - | |||
| 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
History
#1
Updated by G N over 12 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.
#2
Updated by Beat over 12 years ago
- 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.
#3
Updated by Felix Schäfer over 12 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.
#4
Updated by Tharuka Pathirana almost 12 years ago
#5
Updated by Nikolay Kotlyarov almost 12 years ago
and also to #4015
#6
Updated by yac yac over 9 years ago
+1
and i believe this is duplicate of #850
#7
Updated by Toshi MARUYAMA about 9 years ago
- Status changed from New to Closed
- Resolution set to Duplicate