When we export a document (IQA query, business object, content, content type, etc.) today, if that document has custom permissions it will not import into a database that didn't already have that content with custom permissions.  This comes up in the following scenarios:

• Create a new query in Dev, set permissions, test, copy to production.
• Create a generic iPart with permissions, import to new clients.
• Modify the ACL for a query to include a new Role in Dev, then import to Test.
• Import new Nav items we've set up in Dev.

Beside all that, we often have to apply the same permissions over and over to multiple items.  Having our own predefined security sets would make this a lot simpler.  (It would also keep the Access* tables from growing excessively, since each "custom set" is assigned its own key.)

Our workaround has been to reset permissions to a Predefined set, export, import, then reapply the custom permissions.  That's a lot of extra work, and prone to user error.

Is it possible, practical, advisable to create our own Predefined Security Sets?  I can imagine several ways this might work -- any of these would be acceptable.

• A new page in System Setup or iSA or Content Management for adding/modifying/deleting predefined security sets.  GUID field is optional on Add New.  Import and Export would work.  (Best option)
• A stored procedure like asi_InsertSystemConfig to define the security set and others to add and remove specific roles/groups/users/member types to the ACL.  (Second choice because I can save the script and use it anywhere.)
• Documentation of existing business objects which can be used to create and modify security sets programmatically.  (Third choice because it requires programming.  Predefined security sets would be useful even at sites who don't do any development.)

I'd love to hear any suggestions.  I considered poking around the tables to figure out how it works, but hoped there might be an easier way.