Proposal document - Product Container & Libraries

[PRKAC]

Hi All,

Current we are planning to define ACLs across the organization and for which we need to write a proposal document for the following:

• product container and library setup (what product containers +libraries should we have
• when do we decide to have a new product container or library
• should we ever hide/remove product containers
• how do we manage secret projects with containers

Basically looking at best practice/examples for inspiration with a rough explanation of cost vs benefit of splitting out into lots of product containers

Anyone out there who has already established such a setup in their organization and would like to share their experience and possibly a rough guideline on why and how it was established.

Awaiting eagerly to hear back from the community:)

Regards,

PRKAC 

[joe_morton]

We've been slowly building guidelines by trial and error. We are using workflows in Windchill for approving different objects within each Product/Library. As such, the most defining feature for when you need a new Product/Library is when you need to have a different set of approvers. 

In general, our Libraries house information that is general-use (not specific to a single product). These are mostly read-only to all users, with select people who can add content. 

Users must request access and get approval to have access to a Product. Secret Products wouldn't be listed, and only authorized users can view/edit them.

[PRKAC]

Hi Garnet,

Thanks for sharing the inputs.

By any means do you have a template or set of rules in place that can be shared which defines how things are done?

Looking forward to hearing back from you.

Regards,

PRKAC

[PRKAC]

Hi All,

At this point, we would like to analyze the solution & hear back from the community members if anyone has implemented the same across there organization & have encountered any challenges while doing so. 

Planned Proposal:

Refer to the below attachment.

Regards,

PRKAC

[PRKAC]

Adding to the previous thread...!!!

Also, if the solution presented in pervious is implemented, what are the pros & cons of the solution implementation:)

Looking forward to hearing back from the champs in the community.

Regards,

PRKAC

[BH_9613171]

Product/Library is when you need to have a different set of approvers. In general, our Libraries house information that is general-use (not specific to a single product). These are mostly read-only to all users, with select people who can add content. talktosonic

[MikeLockwood]

Many different approaches have been used over the years - spreadsheets, diagrams, etc.  Your diagram looks very good compared to most.

It's 5-dimensional and a good puzzle:

WHERE: Site, Org, Product, with inheritance unless overridden by lower

WHAT: Object type, with inheritance unless overridden by sub type

WHEN: At what state (for lifecycle controlled object types); inherits from ALL when used

WHO: This is especially tricky because of: Guest Role, Team Members pseudo-Role, Teams at Site/Org and context Teams, Team instances also formed for each object instance and other factors.

DO WHAT: The permissions (Create, Read, Download, Revise, etc.).  There are 3 permissions for Move that don't include the word move and are very confusing.  Can also use Grant / Deny.  Can also apply to Principal or all except.  More here...

WHO is also confusing because Roles are used for both assigning access (ACLs) and assigning workflow tasks.  Most get these confused and end up with a bit of a mess.

ACL's are subject to a set of properties in wt.properties that include "implies" which are responsible for the system auto-selecting when a user selects.  I've hated these for 15+ years and always set all to null on every system. The most damaging is: When you select Revise, the system also selects Modify. One always Revises from RELEASED but in no system can users Modify at Released. It's 100% wrong.

On top of this, the use of "Private" for Product/Library contexts is really a good tool, not understood by many.  Greatly simplifies Products/Libraries with unique needs.

Products / Libraries created from OTB templates include all ACLs in the context. Super inefficient and laborious to make changes.  Every admin quickly learns to move all common ones to Org level and delete from each Product/Library. Key to this is having your own templates for Product/Library and creating all from those.

Also, the object types CABINET and SUBFOLDER are important.