cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Learn all about the Community Ranking System, a fun gamification element of the PTC Community. X

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

mrump
16-Pearl

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

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?

 

 

ACCEPTED SOLUTION

Accepted Solutions
awalsh
17-Peridot
(To:mrump)

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. 

 

View solution in original post

1 REPLY 1
awalsh
17-Peridot
(To:mrump)

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. 

 

Announcements


Top Tags