Feature #4049


Permission management on a per project basis

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

Permissions and roles
Target version:
Start date:
Due date:
% Done:


Estimated time:


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 levelNew2009-10-10

Is duplicate of Redmine - Feature #850: Per-project role permissionsNew2008-03-14

Actions #1

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 #2

Updated by Beat   over 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 #3

Updated by Felix Schäfer over 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 #4

Updated by Tharuka Pathirana about 14 years ago

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

Actions #5

Updated by Nikolay Kotlyarov about 14 years ago

and also to #4015

Actions #6

Updated by yac yac almost 12 years ago


and i believe this is duplicate of #850

Actions #7

Updated by Toshi MARUYAMA about 11 years ago

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

yac yac wrote:


and i believe this is duplicate of #850

Thank you for your feedback.


Also available in: Atom PDF