My use-case is simple requirements management...
The Business Owner creates an Issue with Type="Requirement". This is the top of our requirement hierarchy. (All such requirements for a release are grouped into a structure which noe functions as the view for that product release)
The Product Owner then creates product level requirements (Issue Type also equals "Requirement") that meet the intent of this business requirement and organizes them directly underneath the business level requirements. He should only have "view" access to the Business level requirements.
At this point the top most level = Business requirements.
The next level down = Product requirements.
Implementation Primes create stories, Issue Type = "Story" below each of the Product Owner requirements. Implementation primes can not change or move Issue Type = "Requirement" issues in the structure, but can manipluate the stories they have created.
An individual Designer can create "tasks" as necessary under these the "Story" issue types.
I need a way to enforce permissions at a layer in the structure or issue Type.
Issue Type permissions would ideally allow the creator of an issue to modify its contents (Title, description, etc.) or re-organize it within the structure. The downside is that it limits collaboration and division of work in real-time. The originator must be the one to make all changes.
Different permissions at differnt structure levels would allow certain users access to specific layers of the decomposition. But I am worried that an implementation would bee too complex without limiting the ability of the Business Owner and the Product Owner to use the hierarchy to full effect as this would require the ability to associate a set of permissions and users to each level per Business level requirement (Ick). Essentially to be able to designate on a per requirement decomposition hierarchy key levels in the decomp at which certain groups are now allowed to continue from, but not make changes to the items above that point in the decomp. (Hope that makes sense).
Mike
My use-case is simple requirements management...
The Business Owner creates an Issue with Type="Requirement". This is the top of our requirement hierarchy. (All such requirements for a release are grouped into a structure which noe functions as the view for that product release)
The Product Owner then creates product level requirements (Issue Type also equals "Requirement") that meet the intent of this business requirement and organizes them directly underneath the business level requirements. He should only have "view" access to the Business level requirements.
At this point the top most level = Business requirements.
The next level down = Product requirements.
Implementation Primes create stories, Issue Type = "Story" below each of the Product Owner requirements. Implementation primes can not change or move Issue Type = "Requirement" issues in the structure, but can manipluate the stories they have created.
An individual Designer can create "tasks" as necessary under these the "Story" issue types.
I need a way to enforce permissions at a layer in the structure or issue Type.
Issue Type permissions would ideally allow the creator of an issue to modify its contents (Title, description, etc.) or re-organize it within the structure. The downside is that it limits collaboration and division of work in real-time. The originator must be the one to make all changes.
Different permissions at differnt structure levels would allow certain users access to specific layers of the decomposition. But I am worried that an implementation would bee too complex without limiting the ability of the Business Owner and the Product Owner to use the hierarchy to full effect as this would require the ability to associate a set of permissions and users to each level per Business level requirement (Ick). Essentially to be able to designate on a per requirement decomposition hierarchy key levels in the decomp at which certain groups are now allowed to continue from, but not make changes to the items above that point in the decomp. (Hope that makes sense).