Feature #4049

Permission management on a per project basis

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

Status:ClosedStart date:2009-10-18
Priority:NormalDue 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

Related to Redmine - Feature #4015: Make app settings overridable at project level New 2009-10-10
Duplicates Redmine - Feature #850: Per-project role permissions New 2008-03-14

History

#1 Updated by G N about 11 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 10 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.

#3 Updated by Felix Schäfer over 10 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 over 10 years ago

Seems, this is related to #1853 / #2076?

#5 Updated by Nikolay Kotlyarov over 10 years ago

and also to #4015

#6 Updated by yac yac about 8 years ago

+1

and i believe this is duplicate of #850

#7 Updated by Toshi MARUYAMA over 7 years ago

  • Status changed from New to Closed
  • Resolution set to Duplicate

yac yac wrote:

+1

and i believe this is duplicate of #850

Thank you for your feedback.

Also available in: Atom PDF