Feature #5605

Subprojects should (optionally) inherit Members from their parent

Added by Thomas Martin over 7 years ago. Updated over 4 years ago.

Status:ClosedStart date:2010-05-27
Priority:NormalDue date:
Assignee:Jean-Philippe Lang% Done:

0%

Category:Projects
Target version:2.3.0
Resolution:Fixed

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

Related to Redmine - Feature #1878: Inherit parts of parent project by subprojects New 2008-09-09
Related to Redmine - Patch #13065: German Translation for r11299 Closed
Duplicated by Redmine - Feature #7401: Member Inheritance between projects and subprojects Closed 2011-01-21

Associated revisions

Revision 11298
Added by Jean-Philippe Lang almost 5 years ago

Optionaly inherit members from parent project (#5605).

Revision 11299
Added by Jean-Philippe Lang almost 5 years ago

Adds :field_inherit_members string to locales (#5605).

Revision 11301
Added by Jean-Philippe Lang almost 5 years ago

Typo that triggers an error when editing a subproject (#5605).

Revision 11302
Added by Jean-Philippe Lang almost 5 years ago

Typo that makes the checkbox not visible (#5605).

Revision 11310
Added by Jean-Philippe Lang almost 5 years ago

Adds a warning for when a user with inherited permissions disables inheritance (#5605).

Revision 11312
Added by Jean-Philippe Lang almost 5 years ago

Don't display the warning to administrators (#5605).

History

#1 Updated by Tharuka Pathirana over 7 years ago

Related to #2076?

#2 Updated by Marco Wlotzka over 7 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

#3 Updated by thomas wang about 7 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

#4 Updated by Albert Rosenfield about 7 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.)

#5 Updated by Petr Pospisil about 7 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.

#6 Updated by Ian DeFazio almost 7 years ago

+ 1

#7 Updated by Terence Mill almost 7 years ago

+1

#8 Updated by Michael Fairchild almost 7 years ago

+1

#9 Updated by Matthias Geier over 6 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.

#10 Updated by Bitt Sitt over 6 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.

#11 Updated by Sylvain Bannier over 6 years ago

+1

#12 Updated by Fernando Hartmann over 6 years ago

+1

#13 Updated by Mischa The Evil about 6 years ago

Added relation to #1878.

#14 Updated by Anonymous almost 6 years ago

+1

#15 Updated by Egidijus Zideckas over 5 years ago

+1

#17 Updated by Rafael Amorim about 5 years ago

+1

#20 Updated by Nik G about 5 years ago

+1

#21 Updated by Adriano Ceccarelli about 5 years ago

+ 1

#22 Updated by Fred Leeflang about 5 years ago

+1

#23 Updated by Sebastian Hucke about 5 years ago

+1

#24 Updated by Alex Gusarev almost 5 years ago

+1

#25 Updated by Anonymous almost 5 years ago

+1

#26 Updated by Dominik Follmann almost 5 years ago

+1

#28 Updated by Lukas Steinert almost 5 years ago

+1

#29 Updated by Florian S. almost 5 years ago

+1

#30 Updated by Jean-Philippe Lang almost 5 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.

#31 Updated by Ivan Cenov almost 5 years ago

I tested and here is what I saw:

I am manager of P1 project and:
  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.

#32 Updated by Jean-Philippe Lang almost 5 years ago

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

#33 Updated by Jean-Philippe Lang almost 5 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".

#34 Updated by Terence Mill over 4 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

Also available in: Atom PDF