Community Tip - If community subscription notifications are filling up your inbox you can set up a daily digest and get all your notifications in a single email. X
I would really like to have this question clarified, as the manual is not clear about it.
Imagine the following source setup:
We have some SI projects:
/siteA/lineA/prodA/pro111/project.pj
/siteA/lineA/prodA/pro222/project.pj
/siteA/lineB/prodB/pro333/project.pj
/siteB/lineB/prodC/pro444/project.pj
/generic/pro666_forcedReview/project.pj
There shall be a policy for /generic (assuming that the policy is recurse to all proejcts below) that enforces CP review.
There shall be a policy for /siteA (assuming that the policy is recurse to all proejcts below) that does NOT enforce CP review.
When I share a member from (archive) lets say
/generic/pro666_forcedReview/sub1/subSub2/aFile.txt
into
/siteA/lineA/prodA/pro111/subForGenerics/project.pj
Will an update to this member from a sandbox of /siteA/lineA/prodA/pro111/ still be triggering a CP review???
If policies behave like ACLs I'd assume yes, but do they?
Solved! Go to Solution.
Policies behave differently than ACLs. For members, the policy from the current configuration will be used for CP Review - so in your example if /generic/pro666_forcedReview/sub1/subSub2/aFile.txt is modified from /generic/pro666_forcedReview/sub1/subSub2/project.pj, then CP Review is on. If it is modified from /siteA/lineA/prodA/pro111/subForGenerics/project.pj, CP Review will not be used.
For subprojects, it's a bit trickier. By default, policies are inherited from the current configuration. However, a policy explicitly set on the subproject that is shared (not its parent), then it will apply as well to that subproject and its subs.
So, for example, lets say there are the following policies:
And shared subprojects as:
If a user updates a member in /siteA/lineA/prodA/pro111/sharedsub1/project.pj, the CP will not be reviewed. Policies are inherited from /siteA/lineA/prodA/pro111/project.pj which does not have CP Review enabled.
If a user updates a member in /siteA/lineA/prodA/pro111/sharedsub2/project.pj, the CP will be reviewed. Policies are taken from /generic/pro666_forcedReview/sub2/project.pj which has CP Review enabled, then inherited from /siteA/lineA/prodA/pro111/project.pj. If the CP Review OFF policy is locked, then the CP would not be reviewed.
There is an undocumented policy that can be set to make all subprojects honour the canonical location for CP Review: UseCanonicalProjectForCPReview=true
This can be set at the global level. If it is set, the CP Review policies only will be inherited always from the original location. In the example above, both member updates would require a CP Review. Note this only affects shared projects, not shared members. Shared members will always take the current configuration policies.
Policies behave differently than ACLs. For members, the policy from the current configuration will be used for CP Review - so in your example if /generic/pro666_forcedReview/sub1/subSub2/aFile.txt is modified from /generic/pro666_forcedReview/sub1/subSub2/project.pj, then CP Review is on. If it is modified from /siteA/lineA/prodA/pro111/subForGenerics/project.pj, CP Review will not be used.
For subprojects, it's a bit trickier. By default, policies are inherited from the current configuration. However, a policy explicitly set on the subproject that is shared (not its parent), then it will apply as well to that subproject and its subs.
So, for example, lets say there are the following policies:
And shared subprojects as:
If a user updates a member in /siteA/lineA/prodA/pro111/sharedsub1/project.pj, the CP will not be reviewed. Policies are inherited from /siteA/lineA/prodA/pro111/project.pj which does not have CP Review enabled.
If a user updates a member in /siteA/lineA/prodA/pro111/sharedsub2/project.pj, the CP will be reviewed. Policies are taken from /generic/pro666_forcedReview/sub2/project.pj which has CP Review enabled, then inherited from /siteA/lineA/prodA/pro111/project.pj. If the CP Review OFF policy is locked, then the CP would not be reviewed.
There is an undocumented policy that can be set to make all subprojects honour the canonical location for CP Review: UseCanonicalProjectForCPReview=true
This can be set at the global level. If it is set, the CP Review policies only will be inherited always from the original location. In the example above, both member updates would require a CP Review. Note this only affects shared projects, not shared members. Shared members will always take the current configuration policies.