This topic is intended for administrators and developers with administration access rights in Episerver.
From the Episerver CMS admin view, you can define more complex access rights and apply these to parts of the content structure. You most often define access rights for pages or blocks, but you also can define settings for other types of content in the tree structure.
You can define access rights from the edit view, but only for one page or block at the time.
For better control of content creation on large websites, you should base access rights on groups instead of individual users. You can create user groups based on your website structure, for example, Product Editors or News Editors, and add individual users to them. A user can be a member of one or more structure groups.
Depending on the membership provider setup for the website, you can create user groups and accounts outside or inside CMS. When you set up access rights, start by defining the user groups needed and provide access levels for these in the tree structure. Then add individual users to one or more groups.
To gain access to the edit view, an editor must be a member of the default WebEditors group. You then can add an editor to one or more structure groups, depending on their work tasks. See Managing users and user groups.
Access rights are inherited in the content structure. This behavior inherits settings from the closest parent item, applies them to all subitems, and clears existing settings for all items that have inheritance set. All subitems have the same settings as their closest parent item until changed.
To change this, deselect the Inherit settings from parent item option, add the desired user groups or users, and set the desired access rights.
Select one or more of the following options:
|Read||The group/user can read the current content.|
|Create||The group/user can create content under the current content.|
|Change||The group/user can edit the current content.|
|Delete||The group/user can delete the current content.|
|Publish||The group/user can publish the current content.|
|Administer||The group/user can edit dynamic properties and set access rights and language properties on individual content items from edit view.
This does not provide access to admin view (for this you need to be a member of the WebAdmins group).
Apply settings for all subitems applies defined settings for all subitems, in addition to any existing settings. This is used for adding additional settings to subitems that are not inheriting and have different settings from their parent item, without affecting any of their existing settings.
As an example, clearing Read access for the Everyone group hides the selected content item (page in this case) from being publicly visible on the website. Selecting Apply settings for all subitems for the item makes all subitems become publicly invisible as well.
By default, all items in the tree structure inherit access rights from their closest parent item. You can define different settings for specific branches of parent items and their subitems by “stopping the upwards inheritance” and defining new access rights for the parent page. When saved, the new settings apply to subitems that have inheritance set.
In the following example, add the user groups WebAdmins and Product_Sales to the Spring campaign parent page and all its subpages with inheritance.
Do the following:
- On the Admin tab, select Set Access Rights.
- In the tree structure, select the parent item (in this case a page) for which you want to set access rights. The access rights that apply to the item appear. Access rights are by default inherited from the closest parent item. To change the settings for the current item, clear the Inherit settings from parent item check box.
- To add additional groups or users, click Add Users/Groups, and then click Search to find the desired user or user group. Add them one at the time by double-clicking on them. Click OK when you are done.
- Specify the access levels for each user group (or individual user) in the list by selecting either Read, Create, Change, Delete and Publish or Administer.
- Save the settings. The same changes are applied to all subitems that have Inherit settings from parent item set.
In a structure where you already have different settings for different tree branches, you also can add additional settings “on top” of existing ones without affecting these.
In the following example, the Spring campaign page (not inheriting) has three subpages where the Contact information page has specific access right settings, and the other pages are inheriting their settings from Spring campaign. You want to add the user group Customer_Service to all subpages, but without affecting any existing settings on the Contact Information page.
Do the following:
- Select the Spring campaign page in the structure.
- Click Add Users/Groups, find the Customer_Service user group and add it to the list.
- Select access levels, in this case Read, Create, Change, Delete and Publish.
- Select Apply settings for all subitems.
- Save the settings.
The Customer_Service group is added to all subpages, and the specific settings for the Contact information page are left untouched.
To reset access rights to be identical with the parent item, select the Inherit settings from parent item option again, and any specific settings for a subitem are cleared.
The user group Everyone grants anonymous visitors access to public websites by default so that Everyone must have read access to content that you want to be publicly available. You also can create user groups for visitors, letting them view specific “hidden” content that is not otherwise publicly available. This requires a registration and login procedure for visitors to access the content. The feature is useful, for instance, if you want to create a “customer area” for registered customers on your website.
You also can set specific access rights for visitor groupSite visitors with something in common, such as age, geographic location, and so on. Used in the personalization feature of Episerver CMS. (See Personalizing Content.)s but following the instruction as described above but select the Visitor groups type option in the search for Users/Groups dialog.
Visitor groups can have read access only .
Just as for pages, you can apply access rights to assets, such as folders, blocks and media, in the content structure. You can define specific access rights from the "Root" level and all the way down, including the Global Assets that stores blocks and media, and Recycle bin (Trash).
Blocks and media share the same folder structure.
If you want to automatically publish media that are uploaded to the website, editors who upload must have publish access rights in the folder (under Global Assets) to which the media are uploaded. Also, editors must have create access rights in the root level of the website to create blocks.