##Use Role Inheritance

Your existing roles, which contain the shared access rules that are common among all of the secondary roles, should be members of the secondary roles.

###Creating the Base Role For example, let's say that your Base Role, we'll call it "Base Author" has access to all of the Media Libary, and all of your shared content. This will include all of the shared items and Sitecore default roles (as members) that are common among all of the secondary roles. So it might look something like this:

And in Security Editor:

###Creating the Secondary Role So for the purposes of this example, I'm going to call my role "Headmaster Editor". It's a member of the Base Author role.

In Security Editor:

###Assign the Secondary Role only to a user: Adding the secondary role inherits all of the other roles.

##Magic Permission - Breaking Inheritance Breaking the Inheritance of Descendants makes it possible to prevent any access to any content item UNLESS it has been given a Green Check mark in Security editor. Sitecore's role security is strict on "Red X's" for preventing access. Once a role has a Red X, it doesn't matter if other roles have Green Checkmarks, that user won't have access. So, instead of doling out Red X's, break the inheritance, and then only provide given access via Green Checkmarks. I do this by taking the sitecore/Author role, which is out of the box, and breaking the descendent inheritance on the /sitecore/content item.

##Reviewing our Work

Base Author Role

You can see here that Base Author Role only has access to the items that we gave it above.

Headmaster Editor Role

But that the Headmaster Role has everything in the Base + Plus the content from the Headmaster Role.

#In Summary The art and magic of role permissions is to be as simple as possible. If you're checking boxes all over the place and using red x's all over the place, you're doing it wrong. Keep it simple.

Use Role Inheritance

Your existing roles, which contain the shared access rules that are common among all of the secondary roles, should be members of the secondary roles.

Creating the Base Role

For example, let's say that your Base Role, we'll call it "Base Author" has access to all of the Media Libary, and all of your shared content. This will include all of the shared items and Sitecore default roles (as members) that are common among all of the secondary roles. So it might look something like this:

And in Security Editor:

Creating the Secondary Role

So for the purposes of this example, I'm going to call my role "Headmaster Editor". It's a member of the Base Author role.

In Security Editor:

Assign the Secondary Role only to a user:

Adding the secondary role inherits all of the other roles.

Magic Permission - Breaking Inheritance

Breaking the Inheritance of Descendants makes it possible to prevent any access to any content item UNLESS it has been given a Green Check mark in Security editor. Sitecore's role security is strict on "Red X's" for preventing access. Once a role has a Red X, it doesn't matter if other roles have Green Checkmarks, that user won't have access. So, instead of doling out Red X's, break the inheritance, and then only provide given access via Green Checkmarks. I do this by taking the sitecore/Author role, which is out of the box, and breaking the descendent inheritance on the /sitecore/content item.

Reviewing our Work

Base Author Role

You can see here that Base Author Role only has access to the items that we gave it above.

Headmaster Editor Role

But that the Headmaster Role has everything in the Base + Plus the content from the Headmaster Role.

In Summary

The art and magic of role permissions is to be as simple as possible. If you're checking boxes all over the place and using red x's all over the place, you're doing it wrong. Keep it simple.