Policy Management

[srector]

From past threads I have learned how to use the ‘Load From File’ utility to load policy rules en masse. However, as useful as this is, one of the limitations of this approach is that you can only add rules. You cannot modify or delete them.

If you need to delete a number of rules, using this approach, your only options are to delete the rules interactively, or to add ‘deny’ rules to your load file in order to nullify the rules you need to delete.

However, since it is easy to capture all of your policy settings in a report, and then turn that into a csv file for bulk loading, I’m wondering why you couldn’t delete the policies for an entire context and then reload them.

I’m sure there is a catch. Things are rarely as straight forward in Windchill as they appear at first glance. But beyond making sure that there aren’t any open processes dependent on the affected permissions, it seems reasonable. Or I could be completely missing the 800 lb gorilla in the room.

I would appreciate any feedback.

While setting up our system we ran into the need to make significant changes to our policy settings. An approach like this would have made things much less painful.

Thanks,

Steve

[ddemay]

Provided you capture your ACL's exactly the way they are configured to your
liking. There is no reason why you cannot delete them all in the UI and them
reload them with load from file utility. By deleting all of them your
system is wide open or not granted read. Honestly, all the OOTB ACL's are
already sitting in a load file in the loadFiles directory. It gets invoked
everytime you run the command from the load file to refresh a system whole
db was dropped drop user cascade or drop_ddl_wt and readded via the db
script create_ddl_wt.sql



You *could* delete the table with sql (back itup first) and then load the
ootb load file and then load your revised custom ones. Script this and
you're done. Someone really should write a load file java class to just
delete an existing acl.



If this scares you, then, well, don't do it. If you have production data,
don't do it. The data stores its acl setting in a blob, that why it
sometimes takes awhile to update acl's. it has to update each affected
object in various tables. It does it this way I believe as a way to
implement ad hoc acl's in workflows.



No one ever said free advice would always be as easy as 1,2,3. My heads
hurts just after typing this.

[srector]

Thanks for the feedback Dave.

Not sure it is worth the trouble or risk, but at least it gives me an approach to consider.

Steve

[jcrowe]

Steve,

You have expressed a shortcoming that many have had struggles with. I've actually filed a software enhancement with PTC about this lack of functionality(a year ago). Of course, who knows ifthey will actually implement it. The load utilities are a great asset, but onecommonmistake can cause a maintenance nightmare depending on how complicated your policies are. Unfortunately, I don't have a solution, however, just adding my two cents.

[MikeLockwood]

A few notes on this:

1. The load from file functionality is great to load all when a domain is empty - just takes a few seconds once you have it working.

2. But, there is no good way to delete other than going to the database (could be dangerous) - super laborious to delete all one by one, sorting after each delete. Would be great if PTC added mult-iselect to this.

3. There is also no good way thru the UI to find out what ACL's are in place except to laboriously go to each and every domain and take a look - but it is possible to create a relatively simple query builder report that returns all rules for all domains.

4. By far, the best thing is to put as many rules at Org level as possible - and delete them from each Product / Library. Then, create and save Product and Library templates with just the needed minimum (which can be as few as 0).

[ddemay]

All good feedback for PTC during their TC's happening around right about.uh
now. J Yo Needham .what up?













Someone wants to pay a gazillion monopoly dollars, I could probably write a
loader to do the deletion programmatically, look at the ACL API or reverse
engineer (I didn't say that) the ACL applet.







From: Lockwood,Mike,IRVINE,R&D [

[cadjett]

Mike mentions #3:

3. There is also no good way thru the UI to find out what ACL's are in place except to laboriously go to each and every domain and take a look - but it is possible to create a relatively simple query builder report that returns all rules for all domains.

Previously I posted a java tool to parse a WinDU Domain Policy output text file (DomainPolicyRule.txt)to create separate txt & xml files, where the xml can be used to loadfromfile on another box.

Previous post:

http://portal.ptcuser.org/p/fo/st/post=90665#p90665

Readme:

http://www.datajett.com/windchill/wc_dev/ext.ACL_Windu2XML/readme.txt

zip with code, class, examples:

http://www.datajett.com/windchill/wc_dev/ACL_Windu_2_XML_TXT.zip

The method is to run WinDU & out domain policy text file & run class on that output folder. Its parses that text file & outputs:

1) separate copies of the large text file.
2) splits up that same txt file into smaller files (1 for each domain/container)
3) full xml for loadfromfile
4) separate domain/container xml's for each domain/container

One benefit is that the domain/container is set in xml, so the loadfromfile wont need a -CONT_PATH arg.
Another is that the output files are date_time stamped, so you can run 5 times a day/week/month.

Now I had read a few previous posts that covered this area. Deleting, over riding existing ACL.

It sounded as though some one had found or suggested a route to over right existing.

I might look over the posts & see if I can find those suggestions.

But they made it sound like they had tricks to over right, replace existing ACL's.

If anybody knows those tricks, or has their own method, please post to save me the pain of searching...ha..ha

I got the idea of using the Windu from "Prathap Yalavarthi"

http://portal.ptcuser.org/p/fo/st/post=64313#p64313

I tried the other routes suggested (query builder report & sql), but they didnt give me all the data I needed to create a complete loadfromfile xml file/format.

The WinDU DomainPolicyRule.txt file did. It was just in a hard ro read format & not in xml format. So I wrote the java to parse it, extract & write xml file.

L Jett
cadjett@aol.com;datajett@aol.com

[avillanueva]

I just was playing with Import/Export on my system as an alternative to
LoadFromFile. This does not solve the issue of syncing ACLs. You still
cannot delete ACLs using this method but I think if you want to make
sure that ACLs are added consistently across the board, this might work.
The issue with LoadFomFile is that it's a command line and you have to
get the Product or Library Domain path correct. Import/Export you would
call from the UI from each of the Product and Libraries you want to load
the ACL in. No typing command lines. And you can load files from your
workstation and not be at the server machine.



For this snippet, I wanted to add a deny right across the board to my
Products. I used the Product template to get the XML format I needed.





<accesscontrolrule>

<domainname>/Default</domainname>


<externaltypeid>WCTYPE|wt.part.WTPart|myNewSoftType.CISPart</externaltyp<br/>eId>

<lifecyclestate>ALL</lifecyclestate>

<wtprincipalreference isinternal="true">

<groupname>teamMembers</groupname>

<grouptype>ALL</grouptype>

</wtprincipalreference>

<denypermissionset>

<accesspermissionset>

<permissionfield name="CREATE"/">

<permissionfield name="CREATE_BY_MOVE"/">

</accesspermissionset>

</denypermissionset>

</accesscontrolrule>

I took this XML file and zipped it up. For a particular Product, I used
the import UI and loaded that file. Check Resolve Overridable conflicts.
Worked ok. Issue remains for PTC to address is a better UI to sync ACLs.
It would be nice to refresh from template or another context. Don't
forget to update your templates if you make global ACL changes.