ACL: script in order to modify existing ACL

[HenriMarchal]

Hello,

I have understood how to create ACL on a product from scratch. You create your convenient script and you use the command Windchill LoadFromFile etc.

But I'm doing customization on an existing platform: the ACL are already created for the products and I have to modify them. I have not found another way to do it else to do it manually via the GUI for each product . I've tried various scripts but it fails.

Do you know how to do ?

Thank you for your support. I really appreciate this community.

HM

[MikeLockwood]

Absolutely no way provided by PTC on this - have to one by one slug thru the swamp...

So, It's super important to move all possible ACL's up a level where possible - to the Organization - such that there is only one to manage instead of one per Product/Library.

Where they can't be the same, use "Private" for the Product/Library so that it does not inherit ACL's from Org level and can be configured as needed independently.

[HenriMarchal]

Yes you're rigth.

We will refactor completely our ACL's nearly. Most of the things could have been set in the organization...

[MatthewKnight]

Maybe you can delete them, then run your loader

[MatthewKnight]

which entry from csvmapfile? AccessRule?

[HenriMarchal]

My script is adapted from the script that creates the product template. So it does not precise the product name. You must set it via -CONT_PATH option in the loadXmlFile command.

This is my script:

<ProductConfig>
<OrgStructure>
<DomainStructure>
<domainLevel>
<parentDomain>/Private</parentDomain>
<domainName>System</domainName>
<description>The system domain for a context&apos;s administrative objects.</description>
</domainLevel>
<domainLevel>
<parentDomain>/Default/PDM</parentDomain>
<domainName>Default</domainName>
<description>The default domain for a context&apos;s business objects.</description>
<domainLevel>
<domainName>sensitive</domainName>
<description>Domain for the sensitive folder.</description>
</domainLevel>
</domainLevel>
</DomainStructure>
<FolderStructure>
<cabinet>/Default</cabinet>
<domainName>/Default</domainName>
<rootPath>/</rootPath>
<AdHocACLEntrySet></AdHocACLEntrySet>
<nestedFolder>
<name>Sensitive</name>
<domainName>/Default/sensitive</domainName>
<AdHocACLEntrySet></AdHocACLEntrySet>
</nestedFolder>
</FolderStructure>
</OrgStructure>
<ExportedRoleMemberMap>
<projectMember><Role roleType="AUTHOR"></Role></projectMember>
<projectMember><Role roleType="QUALITY"></Role></projectMember>
<projectMember><Role roleType="STRESS"></Role></projectMember>
<projectMember><Role roleType="ESCALATOR"></Role></projectMember>
<projectMember><Role roleType="VALIDATOR"></Role></projectMember>
<projectMember><Role roleType="MEMBERS"></Role></projectMember>
<projectMember><Role roleType="CONFIGURATION MANAGER"></Role></projectMember>
<projectMember><Role roleType="TEAM LEADER"></Role></projectMember>
<projectMember><Role roleType="LIBRARY MANAGER"></Role></projectMember>
<projectMember><Role roleType="READ PUBLIC"></Role></projectMember>
<projectMember><Role roleType="MANUFACTURER"></Role></projectMember>
</ExportedRoleMemberMap>
<ExportedTemplateFiltering></ExportedTemplateFiltering>

<!-- BEGIN ACLs For the CONFIGURATION MANAGER Role for ECDocuments -->

<AccessControlRule>
<domainName>/Default</domainName>
<externalTypeId>WCTYPE|wt.doc.WTDocument|corp.eurocopter.eu.ECDocument</externalTypeId>
<lifecycleState>INWORK</lifecycleState>
<WTPrincipalReference isInternal="true">
<groupName>CONFIGURATION MANAGER</groupName>
<groupType>DynamicRole</groupType>
</WTPrincipalReference>
<grantPermissionSet><AccessPermissionSet>
<permissionField name="SET_STATE"></permissionField>
</AccessPermissionSet></grantPermissionSet>
</AccessControlRule>
</ProductConfig>

post edited by Henri Marchal

[MatthewKnight]

I don't have time to look into it but I think in 9, wc uses wt.access.LoadAccessControlRules for that. This class looks like it should handle update. I'll come back to it if I find any time today. Good luck

[HenriMarchal]

I decided to create my own java utility to update ACL's. It reads a txt file where the ACL's are defined in an home-made format and then it uses a PTC's function to launch the update query.

The function is wt.org.StandardAccessControlManager.newStandardAccessControlManager().updateAccessControlRule(domain, type, state, principalRef, grants, deny);

At last, it looks fine !

But I do not achieve to solve a (maybe) last problem: the principalReference. My ACL's apply to roles and Role.java does not extend WTPrincipal.java. I must use wt.org.WTRolePricipal.java.

But I can't convert my Role in WTRolePrincipal.

Do you know how to proceed ?

Tk u

[ptc-3143537 · Accepted solution]

Henri,

Congratulations on being brave enough to tackle this. I did and it's not as easy as it looks. That said, I cannot give my code to update ACL's from load files away, but I can answer you question:

WTRolePrincipal extends WTGroup, however it is not a principal in a classic sense that it is store din LDAP. That is why the OrganizationServicesHelper will fail when it tries to search LDAP for a dn.

WTRolePrincipal does have its own table in the database. It starts out completely empty. The only way I have found to add entries there is if you create a Role based ACL using the Policy Administrator applet. No publicly available command line tool exists to solve this as of right now. I did plan on perhaps releasing mine in coming months.

What I had to do was query for the WTRolePrincipal object and if it did not exist, create it and persist it. Only then, could I pass it as a reference to the AccessControlHelper.service.updateAccessControlRule() or its similar create or delete methods. Note that if the WTRolePrincipal object already exists, you do not need to create it again. Similarly, if you delete an ACL's that used a WTRolePrincipal object, it, the role, is not removed, only the ACL entry.

Good luck, this information i am providing took me awhile to figure out and hopefully your script will benefit from these pointers.

My script actually improves upon the ACL's load file java code, I would encourage you to not reinvent the wheel and stick with the CSV/XML Load file technology as it's quite powerful once you know how to use it.

David DeMay

[MikeLockwood]

Hello Mike,

We believe you have responded to this email notification in error. If you still wish to reply to Henri Marchal, you may still do so by following this link and replying directly to the discussion, View the full discussion. A simple copy and paste should minimize any extra effort on your part.

Thank you,

The PlanetPTC Community Team

From: Lockwood,Mike,IRVINE,R&D [mailto:Mike.Lockwood@AlconLabs.com]
Sent: Tuesday, August 16, 2011 11:29 AM
To: community
Subject: RE: [Windchill] - ACL: script in order to modify existing ACL

Attached report may be helpful – for getting info out.

We actually run this from Excel, in a macro that puts all the new info on a new worksheet and compares to previous. But – the macro is not currently working and I don’t know why.

From: HenriMarchal [mailto:-]
Sent: Tuesday, August 16, 2011 7:37 AM
To: Lockwood,Mike,IRVINE,R&D
Subject: Re: [Windchill] - ACL: script in order to modify existing ACL

ACL: script in order to modify existing ACL reply from Henri Marchal in Windchill - View the full discussion I decided to create my own java utility to update ACL's. It reads a txt file where the ACL's are defined in an home-made format and then it uses a PTC's function to launch the update query. The function is wt.org.StandardAccessControlManager.newStandardAccessControlManager().updateAccessControlRule(domain, type, state, principalRef, grants, deny); At last, it looks fine ! But I do not achieve to solve a (maybe) last problem: the principalReference. My ACL's apply to roles and Role.java does not extend WTPrincipal.java. I must use wt.org.WTRolePricipal.java. But I can't convert my Role in WTRolePrincipal. Do you know how to proceed ? Tk u Reply to this message by going to PlanetPTC Community Start a new discussion in Windchill at PlanetPTC Community

---

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments.

Thank you.

[HenriMarchal]

Yes, to implement the feature into csv/xml load file should have been the best but... developpers lack of time as usual.

However, it works.

thank you all for your advice.