Feature #5605
closedSubprojects should (optionally) inherit Members from their parent
0%
Description
alternatively, the "Roles & permissions" section should have "View subprojects" and "Edit subprojects" check boxes.
This is somewhat related to issue#4763.
Thanks!
Thomas
ps: "Subprojects" is an ideal mechanism to organize complex projects in a hierarchy (devide & conquer) and thus increase the overall quality of the project management by increasing the accuracy of time estimated, reducing redundancy and promoting synergy - at the planing stage. A prerequisite for the potential benefit is, however, definition of suitable semantics for the concept of "Subprojects". Intuitively, subprojects (by default) inherit (almost all) of their parents properties. - For properties like "Estimated time", "% Done", "Priority" parent-projects show & consider the cumulated values of all given subprojects.
Related issues
Updated by Anonymous about 14 years ago
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
Updated by thomas wang almost 14 years ago
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
Updated by Albert Rosenfield almost 14 years ago
+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.)
Updated by Petr Pospisil almost 14 years ago
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.
Updated by Matthias Geier over 13 years ago
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.
Updated by Bitt Sitt about 13 years ago
+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.
Updated by Jean-Philippe Lang over 11 years ago
- Subject changed from subprojects should (optionally) inherit Members from their parent to Subprojects should (optionally) inherit Members from their parent
- Status changed from New to Closed
- Assignee set to Jean-Philippe Lang
- Target version set to 2.3.0
- Resolution set to Fixed
Feature added in r11298. Subprojects can now inherit members from their parent by checking the Inherit members
checkbox on the project form when creating or editing a project.
Updated by Ivan Cenov over 11 years ago
I tested and here is what I saw:
I am manager of P1 project and:- Created P2, child of P1 with checked on inheritance of members.
- Checked in P2, yes, members are inherited.
- Unchecked the check box.
- 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.
Updated by Jean-Philippe Lang over 11 years ago
Yes, the same warning as when a user removes its project membership should be displayed.
Updated by Jean-Philippe Lang over 11 years ago
Warning message added. If you have inherited some permissoins from the parent project, you'll get a confirmation dialog box when unchecking "Inherit members".
Updated by Terence Mill over 11 years ago
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
Updated by Go MAEDA almost 5 years ago
- Related to Feature #32002: Add inherit_members to projects API response added