Multiple User Groups
Sitekit CMS v 9.6 introduced the ability to assign a user (or Member) to multiple User Groups. All previous versions of Sitekit CMS insisted that a User belong to one single User Group.
The ability to assign a User/Member to multiple User Groups is designed to make User Management easier. Instead of creating a large number of User Groups - each with slightly varying privileges - you can now create a small number of 'building block' Groups, each with a clearly defined function, and assign users to the appropriate groups.
When you first start using 9.6, one Group will be termed the User's 'Master Group'. Initially that master group will, obviously, be set to the User's one and only existing group.
The Master Group
There is a significant difference between the User's Master Group and all other User Groups that a User belongs to. All the CMS Admin rights are taken from the Master Group. The other User Groups are used to define the permissions granted to individual Asset Classes.
The Master Group will be used to access web services which expect only a single user group, rather than several groups (the code exists to send a full list of user groups, and future web services will take advantage of this). If the user belongs (for example) to two groups, one with Admin privileges and one without Admin privileges - then the Group with privileges must be assigned as the Master Group.
The graphic below shows a user being assigned membership of several User Groups. Since this user is an Admin user, their important Administration rights are selected as the Master group.
Advantagesof multiple User Groups?
Example: A web site describes three different products - call them ProductA, ProductB and ProductC, and you wish to limit some editors to just one or two products. Addiitionally you want to limit Publish rights to senior editors only. Even with just three products, that's potentially a lot of combinations, and prior to CMS v9.6 you would have needed to create many different User Groups to cover those combinations.
But in 9.6, you'd only need five User Groups.
What you need to do is set up a User Group called EditorPermissions, which defines the Admin rights you want editors to have. Next you set up three Asset Classes, called ProductA, ProductB and ProductC. Then create three User Groups called EditProductA, EditProductB, and EditProductC. Finally, create a fifth user Group called PublishPages.
Now assign all your editors to use EditorPermissions as their Master Group. Then you can add membership of the other user groups as required. In the graphic below, the Asset Class for ProductA is modified so that only members of User Group EditproductA can create (but not publish) pages in that class.it. Finally, Senior Editors are given membership of the PublishPage User Group, which of couse has Publish rights.
This building block approach makes it a lot easier to construct logical permission sets, rather than creating a bewilderingly large number of user groups.
Least Restrictive Group Rules
In the case of privilege conflicts between two Groups, the Least Restrictive privilege will be applied. So if you belong to two groups, one of which can edit an asset and the other can not - then you will be allowed to edit that asset. This Least Restrictive rule applies in all cases.
New Magic Words and Operator
Several new magic words are provided to work with Multiple Groups. Additionally there is a new operator for the Sitekit if statement, called overlaps. Using this operator you can check a user's list of group memberships, compare it to a selected requirement, and then allow/deny the user access to specific content.This will allow you to construct complex sites, while controlling access to different content with simple Group Rules, (This new operator can be used with all strings - it's not limited to checking User Group membership).