0008373: Parent Projektrights not transmit to Child Projekts (1.0.8) - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update
0008373	mantisbt	sub-projects	public	2007-09-18 09:48	2010-04-23 23:22

Reporter	Caarcrinolas	Assigned To	vboctor
Priority	normal	Severity	major	Reproducibility	always
Status	closed	Resolution	duplicate

Summary	0008373: Parent Projektrights not transmit to Child Projekts (1.0.8)
Description	Hey, if I have Private Projekts like Projekt 1 -> A -> B Projekt 2 Projekt 3 -> A -> A.1 If I give a user for example "developer rights in Projekt 1. They couldn't see the Childprojekt A and B. That's stupid :(
Tags	No tags attached.

vboctor 2007-09-20 01:54 manager ~0015667	The challenge with the way sub-projects are implemented at the moment are: Users use sub-projects on totally different ways, hence, some may want such functionality and others won't. This can probably be resolved via configuration, although it will complicate the code. A single project can be sub-project of multiple other projects, which ones should it inherit rights from?! I've allocated a category for sub-projects that I moved this issue to. The plan is to go through all of these and write up new requirements for sub-project handling and based on that implement a more flexible and consistent model. Volunteers are welcome to participate in the design / development of this feature.

Caarcrinolas 2007-09-20 07:41 reporter ~0015674	hmm you could add to this form a checkbox which mean "get the rights of the root project" This feature reduce the administrative complexity. I think it give no situation where should have a developer the root project and nothing else. All child projects are important for the achievement of the root project

DGtlRift 2007-09-21 12:41 reporter ~0015686	In regards to point 2, IMHO the derived rights should be the maximum allowed permission from inheriting from the union of multiple ancestors. You shouldn't "loose" privileges just because a project becomes a child of a secured project. However, for the specific reason that a manager/admin may want to have a secured project group, at the very least there would need to be some additional information stored in the history log, to indicate "how" a user was able to change some status or do some action against an issue. Additionally, it may be useful to have a "report" that shows what user rights are contradicted/overloaded/overridden in the sub-projects by multiple inheritance.

mbe 2007-09-21 15:25 reporter ~0015689	We are adapting a new version and im reading on subproject. Here is my imput:) We added a field to define a bug as 'generic' or 'specific'. The root project see the child project generic bug's without showing specific ones. We sometimes give access to our customer on the root project so that they can see oncomming developpement for the generic part of their application. We DO NOT want them to be automaticly given rights on child project, since some of them can include oncomming specific developpment for their competitor. To wrap it up, rights inheritance should be triggered by a checkbox, not automatic.