Project

General

Profile

Actions

Feature #850

open

Per-project role permissions

Added by John Goerzen almost 17 years ago. Updated almost 8 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Permissions and roles
Target version:
-
Start date:
2008-03-14
Due date:
% Done:

0%

Estimated time:
Resolution:

Description

I have a situation in which I want any registered user (non-member) to be able to edit wiki pages on all projects except one. There does not at present appear to be a way to express that certain roles have different permissions on a per-project basis, which would be great to have.


Related issues

Related to Redmine - Feature #1853: Make Projects truly independent of each otherNew2008-09-04

Actions
Related to Redmine - Feature #4015: Make app settings overridable at project levelNew2009-10-10

Actions
Related to Redmine - Feature #2539: New project setting: mandatory/optional configuration for target version issue-attributeNew2009-01-19

Actions
Related to Redmine - Defect #16661: Different users sharing same role have rights in projects in which user is not a memberNew

Actions
Related to Redmine - Feature #17500: Visibility/Use-ability/Creation Settings for Issue Trackers per Role per Project.New

Actions
Has duplicate Redmine - Feature #4049: Permission management on a per project basisClosed2009-10-18

Actions
Has duplicate Redmine - Feature #2076: Individual Permissions for Each ProjectClosed2008-10-23

Actions
Actions #1

Updated by Jean-Philippe Lang almost 17 years ago

  • Category set to Permissions and roles

IMHO, it could become quickly hard to maintain permissions if you are able to override them for each project. Also, implementation of cross-project views would become much harder to take care of these permissions.

Instead, I think an other solution would be to have to ability to override the default 'Non member' role at project level (a simple field on the project settings form). For instance, you create a new role with no wiki edit permission (eg. 'Non member on protected projects' or something like that) and you assign this role as the default role to the projects with restricted access.

What do you think ?

Actions #2

Updated by John Goerzen almost 17 years ago

That sounds quite good to me, too.

It would solve this immediate need.

I could see some situations where it wouldn't be adequate, but I don't think I'll ever see them, so I'm fine with your plan :-)

Actions #3

Updated by dj radon about 16 years ago

Any progress. We really want to Corporate/HR/Employee documents to be accessible everybody, but not the documents in other projects.

Actions #4

Updated by dj radon about 16 years ago

That wasn't very clear. What I meant: I think there is no way to have an Employees group that can edit/view the HR project's wiki and docs AND file issues against the software projects without seeing the software projects' documents. Right?

Actions #5

Updated by G N about 15 years ago

I found this ticket after submitting another one for the same issue.

Jean-Philippe Lang wrote:

IMHO, it could become quickly hard to maintain permissions if you are able to override them for each project.

I'm afraid I will have to disagree with the "hard to maintain". Each project may have specific needs. Why should the involvement of the administrator be required in order to, for example, make the "documents" or the "repository" module not available to non-members?

Also, there could be the possibility to reset the project's permissions to the defaults, as defined by the administrator. So, if a project manager screwed things up, he would be able to start over from scratch.

Jean-Philippe Lang wrote:

Instead, I think an other solution would be to have to ability to override the default 'Non member' role at project level (a simple field on the project settings form). For instance, you create a new role with no wiki edit permission (eg. 'Non member on protected projects' or something like that) and you assign this role as the default role to the projects with restricted access.

What do you think ?

This way the administrator will have to create a different role for every special-permission requirement each project may have. I think that it could work for a very small number of projects (2-3), but not if there are several projects, because, first of all, it would complicate the naming scheme of the new roles having special permissions. For example: "developer_non_docs_access", "no_repo_docs_access", "no_repo_access" et cetera.
I believe the management of such roles would end up being harder than giving the opportunity to the project managers to manage the permissions of their own project.

Again, I am against involving the administrator account in such project-specific matters.

Just my 2 cents :)

Actions #6

Updated by Jamie Carl almost 12 years ago

Is there any chance this is going to happen at any point?

I've just hit an issue where I have a single project that I would like to allow anonymous (no login) access to the repository page. With the way things are, I'd have to allow all non-users access to all repos on all projects, which is definitely NOT something I want to do.

Actions #7

Updated by Dipan Mehta almost 12 years ago

There are many duplicates of this feature #4049 & #2076. It is also related #1853.

It is also related to #4015 which I think poses the best solution for all such related tickets.

Actions #8

Updated by Toshi MARUYAMA over 10 years ago

  • Related to Defect #16661: Different users sharing same role have rights in projects in which user is not a member added
Actions #9

Updated by Rafał Lisowski about 9 years ago

Check out https://github.com/efigence/redmine_overwriting_roles

Members who have new permission (:manage_roles) assigned to their role are allowed to overwrite role permissions within the scope of a specific project.
Admin can choose which permissions should be editable and set them in plugin configuration.

Actions #10

Updated by Fabio Peruzzo almost 8 years ago

Rafal, your plugin seems really interesting. I have some difficulties to install it but in a first test it worked, then it had problem.
Have you any experience of installation of your plugin together with Global roles by RM+ ? ([[http://rmplus.pro/en/redmine/plugins/global_roles]]). I would like to create global roles in order to discriminate non-members basing if they are internal or external our company.

Actions #11

Updated by Rafał Lisowski almost 8 years ago

Fabio, we weren't using Global roles plugin. Please test it without Global roles and check if it works. There also may be na issue with Redmine version. Plugin was developed for RM 3.1.

Actions #12

Updated by Fabio Peruzzo almost 8 years ago

I tested the plugin and it works fine, functionality is interesting if you want to reduce number of roles but having anyway the possibility to change project by project. I tried interaction with global roles but they are transparent for overwriting plugin; global roles aren't checked by Redmine when you enter on a project module.
Unfortunately both the plugin aren't what I need. Probably we will develope a plugin for our needs.

Actions #13

Updated by Toshi MARUYAMA almost 8 years ago

  • Related to Feature #17500: Visibility/Use-ability/Creation Settings for Issue Trackers per Role per Project. added
Actions

Also available in: Atom PDF