Skip to main content
S
ssaul15-Moonstone
15-Moonstone
February 15, 2018
Solved

Source: Project Permissions do not seem to inherit to shared subprojects (checkpointing)

  • February 15, 2018
  • 1 reply
  • 1683 views

Project Permissions do not seem to inherit to shared subprojects.
When doing a project checkpoint or snapshot, the ACL of the original location of the shared subproject has to be changed to avoid permission denied errors.
(Where) is this documented?
We are working with shared subprojects very much and getting frequent errors when it comes to checkpointing.

In addition, the affected shared subproject is not shown in the permission denied error message, only the main project. So debugging this error is really hard.

 

Any advice?

Best answer by awalsh

The behaviour of the permissions (ACLs) is documented in the online help: 

https://support.ptc.com/cs/help/integrity_hc/integrity112_hc/en/IntegrityHelp/client_proj_adding_shared_subprojects.mif-1.html

"When working with shared subprojects, Integrity Lifecycle Manager uses the actual name of the subproject in the repository rather than its relative name in the project hierarchy for the purposes of resolving ACLs, policy statements, event triggers, and change package entries. This enhances the portability of change packages across different projects."

 

With regards to checkpoint errors, its a defect if the subproject path is not being given in the permissions error message. This defect should have been fixed in 10.6. If you are using 10.6 or higher, please contact PTC Technical Support to submit a defect.  

 

1 reply

A
awalsh5-Regular MemberAnswer
5-Regular Member
February 16, 2018

The behaviour of the permissions (ACLs) is documented in the online help: 

https://support.ptc.com/cs/help/integrity_hc/integrity112_hc/en/IntegrityHelp/client_proj_adding_shared_subprojects.mif-1.html

"When working with shared subprojects, Integrity Lifecycle Manager uses the actual name of the subproject in the repository rather than its relative name in the project hierarchy for the purposes of resolving ACLs, policy statements, event triggers, and change package entries. This enhances the portability of change packages across different projects."

 

With regards to checkpoint errors, its a defect if the subproject path is not being given in the permissions error message. This defect should have been fixed in 10.6. If you are using 10.6 or higher, please contact PTC Technical Support to submit a defect.  

 

    S
    ssaul15-MoonstoneAuthor
    15-Moonstone
    February 20, 2018

    Thanks for the info - we are still at 10.5 and I did not see this in the version history.

     

    While this won't help for the basic permission problem in shared subprojects, it will definitively help locating the problem.

    Terms & ConditionsAccessibility statement