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 ?
--------------------------------------------------------------------------------
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 :-)
--------------------------------------------------------------------------------
Any progress. We really want to Corporate/HR/Employee documents to be accessible everybody, but not the documents in other projects.
--------------------------------------------------------------------------------
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?
--------------------------------------------------------------------------------
I found this ticket after submitting "another one":http://www.redmine.org/issues/4049 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 :)

--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

relates,New,1853,Make Projects truly independent of each other
relates,New,4015,Make app settings overridable at project level
relates,New,2539,New project setting: mandatory/optional configuration for target version issue-attribute
relates,New,16661,Different users sharing same role have rights in projects in which user is not a member
relates,New,17500,Visibility/Use-ability/Creation Settings for Issue Trackers per Role per Project.
duplicates,Closed,4049,Permission management on a per project basis
duplicates,Closed,2076,Individual Permissions for Each Project