Skip to main content
M
mrump16-Pearl
16-Pearl
March 20, 2018
Solved

how are source policies resolved for a shared member/subproject?

  • March 20, 2018
  • 1 reply
  • 2096 views

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?

 

 

Best answer by awalsh

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:

  • /siteA/lineA/prodA/pro111/project.pj ==> CP Review OFF, not locked
  • /generic/pro666_forcedReview/project.pj ==> CP Review ON
  • /generic/pro666_forcedReview/sub2/project.pj ==> CP Review ON

And shared subprojects as:

  •  /siteA/lineA/prodA/pro111/sharedsub1/project.pj shared from  /generic/pro666_forcedReview/sub1/project.pj 
  •  /siteA/lineA/prodA/pro111/sharedsub2/project.pj shared from /generic/pro666_forcedReview/sub2/project.pj 

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. 

 

1 reply

A
awalsh5-Regular MemberAnswer
5-Regular Member
March 21, 2018

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:

  • /siteA/lineA/prodA/pro111/project.pj ==> CP Review OFF, not locked
  • /generic/pro666_forcedReview/project.pj ==> CP Review ON
  • /generic/pro666_forcedReview/sub2/project.pj ==> CP Review ON

And shared subprojects as:

  •  /siteA/lineA/prodA/pro111/sharedsub1/project.pj shared from  /generic/pro666_forcedReview/sub1/project.pj 
  •  /siteA/lineA/prodA/pro111/sharedsub2/project.pj shared from /generic/pro666_forcedReview/sub2/project.pj 

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. 

 

    Terms & ConditionsAccessibility statement