By Cathy Dew
The Kentico Content Management System is a powerful tool and as your site grows from a single content editor to multiple content editors & multiple languages you’ll want to ensure that your administrative settings are configured properly. Not only will you keep your content safer from editing mistakes, but you’ll also minimize distractions and help your editors stay on task.
There are four primary layers where security is invoked:
- Role (& Memberships)
- Page (& Access Control Lists)
During page construction, Kentico uses these permissions to decide on the proper display and access rights for the requesting user. In some cases, like user and roles, the permissions are additive. If a user or role allows the action, it will be approved. In other cases, like page permissions, there is a defined hierarchy and the page permissions will take precedence over user and role settings. Therefore, if a page directly denies an action while a user or role permission allows it, it will be denied.
While straight forward, if you don’t follow some basic security assignment best practices you can easily open up areas of your site to unintended editing or worse. The simple rule with Kentico permissions is to only make assignments via Roles (and by extension to users by assigning them to Roles). And when you need exceptions to the Role permissions, apply them to the target page or pages.
There is also a Membership collection, that allows you to group roles together and assign users to the Membership collecting instead. This allows you to create some fine tune role permissions and group them differently for different editor and administrative needs. Memberships are great when you have a large website and editor population.
Lastly, when creating a new user there is a default Privilege level assigned to the user account. Kentico has 4 basic privilege levels:
- Global Administrator
These privileges do not assign rights to actions themselves, but provide the framework for the role permissions by allowing none, some, or all access to the administrative interface.
Kentico has a default Editor Role that is provided with the basic editing (create/read/write/delete) permissions to manage content on the site. As you add custom tables, pages, and modules, you will want to visit your Editor Roles and update the permissions to allow your editors to support your new functionally when it makes sense.
The current challenge with the Role Permission administration is the interface provided by Kentico. It only allows you to see only the target custom table, page, or module permissions. You cannot see the “bigger” picture on the permissions, you must visit each item individually.
For modules, you have only two choices for permissions: Read or Modify. With Custom Tables, you have Read, Modify, Create, and Delete. Lastly, for Page Types you have Ready, Modify, Create, Create Anywhere, Delete, Destroy, Browse Tree, Modify Permissions.
All of these permissions should be self-explanatory, but we’ll cover a couple of the less obvious ones.
With Page Types, you can limit the area of the tree where the page types can be created. You can create special roles that are allowed to bypass that limitation and create the target page type outside of it’s recommended branch.
Delete versus Destroy
Deleting puts the object into the recycle bin where it could be recovered, if needed. Destroy removes the object immediately, with no chance of recovery.
You can allow roles / users to change the permissions of a page. This is something that is sometimes needed with larger implementations, and should not be a common occurrence.
Best Practices for Editor Roles
Using the single default editor role work well for smaller sites, but when you need to segregate editor access by branch and / or language you are going to need more than one editor role. Using the clone option, create the extra editor roles you need. You might want to create them by Department, by Language / Culture, or by some other functional division.
You can then bundle these editor roles into Memberships for those accounts that need access to multiple areas. If you don’t need a collection of roles, then you can assign the role directly to each target user account.
This way, you can manage the page editing permissions via the roles and not have to worry about each individual user. A well-defined naming convention will also help you understand at a glance what that editor is allowed to work on. E.g. Editor HR-Spanish, Editor IT-All Languages, or Editor Finance. (As you can see we are partial to the Function – Area/Dept – Culture design pattern.
You are going to need Templates
Once you have the permissions outlined via role, you need to look at designing the templates that will provide the visual framework your editors will work within. Template are the key to making sure your site stay consistent and your editors focused on the content that they are responsible for. A proper template design controls the areas where an editor can put new content, and edit existing content. You should consider designing several templates that would be used when new content areas are created (e.g. Company department pages or Organization chapter pages). This way there is some flexibility in the content creation process, but the editor is locked-in and can’t change the base look and feel of the page.
Widgets – What are they?
Once part of Kentico that takes a bit of experience to understand is the difference between web parts and widgets. This difference is really important when it comes to template design and editor content creation. Web parts are a base element in Kentico and provide all the features and functionality of the page without all of the heavy lifting by a developer to design and configure. You grab the web part you need (based on the features you want to use) and configure the settings of the web part. (This is an over simplification, but the important aspect is the web part is reusable across the site and requires no coding to implement.)
When you design templates, any web part you put on the page that is not part of an editor zone is not configurable by the editor. These web parts become “fixed content” for the editor. Also, the editor cannot select a web part and use it within their editor zone. In order to allow an editor to use a web part you must create a widget based on an existing web part. The new widget will have all the same features of the parent web part, with the additional feature of being usable within an editor zone.
The catch with widgets is once you create one, they are a separate object than the source web part. And updates to the web part do not cascade down to the widget. If you create a custom web part, create a widget from that, and then update the web part with additional features – you will need to create a new widget from the revised web part and replace all the v1 widgets with v2.
As you can see, building a proper editing environment in Kentico while straight forward does require some pre-planning in order to provide a well-defined and well-structured CMS. If you are just starting out using Kentico or need help managing your legacy Kentico environment, 2Plus2 has the expertise to help you build a scalable solution. Go online to schedule a free consultation with our team or call 510-652-7700 today.