We have sorted our use cases into a hierarchy of packages, like the example below.
Package Level 1
Package Level 2
Package Level 3, Package A
Use case A
Package Level 3, Package B
Use case B
The first level represents the organisation's value streams, the second represents different areas within each stream, while the third one is to version control each use case individually; setting Version, Status and creating a baseline.
We want the requirement analyst to be able to version control on the third level, by using the Update Status command. We also want them to be able to create new packages/use cases on the third level. But we don't want them to be able to do either of that on the first or second level.
Currently all levels are locked to the user group "RequirementAnalyst". The problem is that a user may accidentally change the Version and Status of a package on Level 1 och Level 2. The change will then propagate to all the child packages, since this is the default behavior of Update Status.
If I try to restrict Level 1 and Level 2, by locking them to the group "RequirementManager", all newly created packages on Level 3 will inherit the lock, making it impossible for the requirement analysts to version control them.
Is there some other way to restrict the scope of Update Status and block it from propagating through the package levels? I know you are able to uncheck Recursively update all child packages in the Update Status dialogue. Unfortunately that box is checked by default, but I suspect a system administrator will be able to tinker with the setting and possibly also make it impossible for users to change it.
