Redmine

Related to #2076?

Hi,

We need this feature, too. We have subprojects belonging to subdirectories in the same svn repo. I like the way to authenticate against svn only via redmine. (Redmine.pm). But the permissions aren't inherited from the super project.

like this:

super-project <= Member1, Role:Developer |sub-project <= Member1 from super-project (failed)

A quickfix was using Groups:

super-project-developers <= Member1

super-project <= super-project-developers, Role:Developer |sub-project <= super-project-developers, Role:Developer

So I can add users to the group "super-project-developers" and there have same permissions on both projects
But: Managers arent' capable in changing members of groups, and I don't want them to become admins.

Any Suggestions?

Cheers, Marco

Hey guys,I wonder if there is a function that subprojects can inherit the root's Members & Roles,or a project's Members and its Roles can be selected to apply for other projects,that would save lot of time

+1

except there is no need for this to be optional nor editable, permissions should just always flow from projects to subprojects.

(like most, if not all, good tree-based ACL system.)

Please add this feature to the Redmine. At a process of creating a new sub-project I would like to say something like "inherite members (permissions)", "inherite modules", "inherite custom fields" etc. Thank you. At this moment when I have a subproject(s) and a new member come in than I have to add him to all projects separately.

+ 1

+1

+1

What about adding something like dynamic groups?

In "Settings->Members->New member" now there is a list of all users followed by a list of all groups.
After that, there could be some automatically generated items like

• All parent project members with the role Manager
• All parent project members with the role Developer
• ...
• All top-level project members with the role Manager
• All top-level project members with the role Developer
• ...

This way the project manager would have full control which roles to assign members of the parent project and the top-level project, respectively.
For example, you could specify that all Developers of the parent project should get the role Visitor in this project.
If the parent project doesn't have members of a certain role - or if it's a top-level project - no list items should be generated.
If projects are moved around in the hierarchy, maybe these kind of permissions should be removed because they probably don't make sense in the new context.

The actual names of the dynamic groups should probably contain the full name of the parent project and the top-level project, respectively. Let's say you have a parent project Syntax Highlighting, then the list entries could look like this:

• All members of Syntax Highlighting with the role Manager
• All members of Syntax Highlighting with the role Developer
• ...

This could be extended to be a solution to #7342 by introducing a new dynamic group

• All registered users

Of course, the assignment of users to dynamic groups cannot be fixed (or even cached?), they have to be evaluated at each access.
So if a member is added in a parent project, this should be propagated automatically to the relevant sub-projects.

+1

If you add a member to a project, it would also be nice with a checkbox "Add to subprojects" so that if a new member enters the team, he can easily be given access to all subprojects.

+1

+1

Added relation to #1878.

+1

+1

+1

+1

+1

+1

+1

+ 1

+1

+1

+1

+1

+1

+1

+1

+1

I tested and here is what I saw:

1. Created P2, child of P1 with checked on inheritance of members.
2. Checked in P2, yes, members are inherited.
3. Unchecked the check box.
4. Saved the form, Redmine rendered 403.

This is obviously. All members, including me as Manager were un-inherited.

I propose that some validation of the form, when saving it to check if such situation may happen and at least to show an alert with a text something like "Are you sure doing thing. You will loss the control of the project."

P.S. It happened, because I as not member (removed member), cannot see Setting tabs.

Yes, the same warning as when a user removes its project membership should be displayed.

Warning message added. If you have inherited some permissoins from the parent project, you'll get a confirmation dialog box when unchecking "Inherit members".

The hierarchy paradigm is not adopted well in some of the reports.
For example Sumary does not report on issue of subprojects. If members areinherited there shall be at least an option "show subprojects" to click to also include childs projects issues. It must recognize that there are also additional tracker in child projects possible.

I created an issue for this #12492