SDL Tridion Parent Publication Permissions Simplification

Here are some SDL Tridion patterns I like that fit a "don't overdo flexibility" mantra.

• Minimize content publications
• Minimize localization
• Make multiple schemas but reduce redundant work through embeddable schema
• Simplify selections by using Category and Keywords for text fields

Let's add one more: simplify permissions management. As promised, here's an implementation for a "brain-twisting requirement to manage permissions from a single parent publication." This can reduce the need to break inheritance or localize folders throughout the BluePrint and simplify your authorization model for the cost of some extra groups.

I really have to see and prove this out for more scenarios but so far this setup looks promising (i.e. test this out before going live).

1. Use default rights groups as parents (e.g. Author, Editor, Chief Editor)
2. Create subgroups for scope and permissions (e.g. Editor Global and Editor Local)
3. Set these as children of the default groups, with scope set to a specific publication (level)
• Editor Global is a member of Editor with 020 Content scope
• Editor Local is a member of Editor with 040 Website scope
4. Create "roll-up" groups such as All Authors and set these as children of the subgroups.

In your highest content publication, set folder permissions according to the following.

In this example, we want editors to see and edit components in this folder in 020 Content. Because the Editor Global membership scope to the Editor group is restricted to 020 Content,  both the Editor Global and its child group Editor All will have read and write permissions.

But we may not want editors write permissions in a lower publication. Because the Editor Local membership scope to the Editor group is restricted to 040 Createandbreak, both the Editor Local and its child group Editor All will have only read permissions.

For the "cost" of an additional roll-up group (and more subgroups, depending on how you handle scope versus permissions-based groups), you can:

• Manage most author permissions in fewer (a single publication if you create most folders in 020 Content) publications
• Set users to an "all" roll-up group and get combined publication scope and permissions--add a user to this group and they get the combined, yet separately managed, permissions, rights, and publication scope
• Have the flexibility to mix-and-match subgroups if needed

Reminder: only change the "All Publications" scope setting for the subgroup membership. Leave the user membership, the roll-up group membership, and the "available for setting permissions" set to "All Publications."
See update below.* Manage your unique changes, not everything. 

Now, anyone have some good tip on session and user management to test this all out?

Update: the full setup can include "ACL" groups for even read and write permissions across similar folders. Each time you set up a global folder, you could place it as part of (maybe a same-named) group for each. It's a bit extra work in the setup, but troubleshooting and managing this means you can add full sets of permissions just be adding/removing membership.

With an "ACL setup" you'd set "All Publications" for everything. But if only doing roll-up groups, you may need to adjust the scope membership settings as needed (e.g. the Editor All would belong to Editor Local with scope just set to the "Local" publication and so forth).