This topic is intended for administrators and developers with administration access rights in Episerver.
By using access rights in Episerver CMS, you can control the content that a website visitor sees, and what editors can do and where they can do it in the content structure. For example, you may give members of the marketing department access to edit the website marketing material that other company users should not edit. You can set access rights for different types of content, such as pages, blocks, images and documents in the navigation and assets panes.
You can also use access rights together with visitor groups and give a visitor group from a local 10-mile radius access to an advertisement page.
Access rights are normally managed from the administration view in Episerver CMS, but you can give editors the right to manage access rights for a single page in edit view.
You can watch the following demonstration video, Managing access rights. (6:39 minutes)
Different types of access
You can grant or deny the following types of access to users and groups: Read, Create, Change, Delete, Publish, and Administer.
|Read||The user or group can access the content as a reader; otherwise the content is invisible.|
|Create||The user or group can create content under the content item on which this right is set.|
|Change||The user or group can access the content to modify it. Typically, Create and Change are set together but there may be cases where you want someone to modify created content (but not create their own content), or vice versa.|
|Delete||The user or group can delete the content.|
|Publish||The user or group can publish the content.|
|Administer||The user or group can create and edit approval sequences, and set access rights and language properties on individual content items from edit view for content given this access.
This does not provide access to admin view. To access admin view, you need to be a member of the WebAdmins group, see Built-in user groups).
Access rights to assets
Just as for pages, access rights can be applied 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 Recycle bin (Trash) and For All Sites that stores blocks and media. Blocks and media share the same folder structure.
Editors must have Create access rights to the global or site-specific folder under For All Sites/For This Site where they want to upload an image or create a block, or to the current page when adding assets to the local For This Page folder. If media should be automatically published when they are uploaded, editors who upload must have Publish access rights, either to the global or site-specific folder or to the page, if media are uploaded to the local folder.
See Folders for a description of global, site-specific and local folders.
Media are never automatically published if an approval sequence has been set on the folder to which the media are uploaded.
Should I set access rights for a single user or for a group?
You can set access rights to content for a single user. For example, you can set the access rights so only Ann (and system administrators) can edit the Book a Demo page. You can add Ann to any number of pages and content, and set Ann's access rights to each content item the same (or differently) for each page.
If you have a number of users that need common access to content, managing access rights on a user-by-user basis can be complex. Create user groups that have similar access needs, add the users to each user group, and then use the user group to set access rights to content. This lets you manage access rights more easily. You can add a user to one or more groups.
For example, add users Ann, Bob, and Cam to a Marketing user group and give access rights to any number of pages and content to the Marketing group instead of each individual. To add Dan to all of the Marketing content, (or remove Ann), you modify the Marketing user group. You do not have to visit each page or content item to update each individual user's access rights.
By default, Episerver CMS has built-in user groups that align with user roles. You can extend predefined groups and roles; see Managing users and user groups.
When your website is set up during development, the membership and role providers available for your website need to be configured to use the built-in groups and roles in Episerver.
|Administrators||Comes from Windows and is defined when the website is created. An administrator can access all parts of the system, and can edit all website content. Often, administrators are developers setting up or maintaining the website.|
|WebAdmins||Comes with Episerver and can access both admin and edit views and the administration interfaces for add-ons and visitor groups. To use this group, you must add it through admin view > Admin tab > Access Rights > Administer Groups > Add > WebAdmins.
Membership in WebAdmins does not provide editing access in the content structure by default. In most cases, only a few system administrators or "super users" belong to this group.
Comes with Episerver and can access the editing view. To use this group, you must add it through admin view > Admin tab > Access Rights > Administer Groups > Add > WebEditors.
Add users to this group who need access to the edit view. Then add the users to other groups to give them specific edit rights to content. On large websites, editors are often organized in groups according to content structure or languages.
|Everyone||Comes from Windows and provides "anonymous" visitors with read access to website content. All unregistered visitors to a public website are anonymous, meaning that they cannot be identified by the system. Removing access rights for the Everyone group, requires login to access content even if it is published.|
- Go to admin view > Admin tab > Access Rights > Set Access Rights. The Set Access view appears with a content tree structure of the website.
- Click a node in the content tree (for example, Marketing). Typically, a content item shows Administrators (with all access rights) and Everyone (with Read only access rights). You can change these rights or add new users or groups.
- If the users or groups are inactive (grayed out) for a content item, then the content item inherits the access rights of its parent content item. To set access rights for this content item, clear the Inherit settings from parent item check box.
- To add settings to the selected node's subitems without affecting their existing settings, select the Apply settings for all subitems; see section Setting access rights for all subitems below.
- Click Add Users/Groups. A dialog box appears.
- Select the type you want: Users, Groups, or Visitor Groups.
- Leave the Name field blank and click Search to display all items of the type you selected. You can also type one or more characters in the Name field to filter and display a subset of items. (You can also search for a user by E-mail address.)
- Double-click a user or group in the Existing box to move it to the Add box and click OK.
- Modify the access rights settings as you want them and click OK. The users or groups appear in the Set Access Rights view for the selected content tree item.
If you set conflicting access rights to content, selected access rights prevail over cleared access rights. For example, Ann is a member of both the Marketing and Support user groups which each have different access rights set on the same content; Marketing has Publish rights, but Support does not. Ann, who is in both groups, has Publish rights to the content, but Bob, who is part of the Support group only, does not have Publish rights.
Content inherits access rights from its closest parent item by default. When you set access rights for a content item, the rights apply to it and all subitems that have a selected Inherit settings from parent item option; subitems with this option cleared are not affected. For example, Alloy Plan, Alloy Track, and Alloy Meet all have the same access rights because they inherit the access rights from the Start page.
- If you break inheritance for Alloy Meet and change the access rights on it, the access rights become different from the parent (Start) and its two siblings (Alloy Plan and Alloy Track).
- If you then add a Marketing group group to Start, Alloy Plan and Allow Track inherit the Marketing group (because inheritance is selected) but Alloy Meet does not because its inheritance is unselected.
The following image shows the access rights for the Marketing content; it will not inherit from the parent item and any changes of access rights on Marketing will not be pushed to subitems unless they have the Inherit settings from parent item option selected.
Campaigns is a subitem of Marketing. It has Inherit settings from parent item selected, so the access rights are identical to that of the Marketing content item.
Book a demo is also a subitem of Marketing, but contrary to Campaigns, it has Inherit settings from parent item cleared, so its access rights are not the same as the Marketing parent content item. (Ann does not show up, and Zach is listed in the access rights.)
Selecting the Apply settings for all subitems check box applies the access rights of the parent item to all its subitems, even if a subitem has inheritance cleared. The option adds settings to a subitem that it did not have before and does not change or remove any existing settings on the subitem.
For example, the Marketing content item has Ann as a user with access rights.
When you select Apply settings for all subitems, Ann is added as a user with access rights to Book a demo because Ann is part of the Marketing content item's access rights. Zach, who already had access rights to Book a demo, remains on the list of access rights, unchanged.
If a parent item and a non-inheriting subitem have the same user or group, and the access rights for the user or group differ between the parent and the subitem, the parent's settings are applied when you select Apply Settings for all subitems. For example:
- If the Marketing parent item has user Ann with only Read access set, and Book a Demo has user Ann with all access rights set, then Apply Settings for all subitems resets Ann's access rights on Book a Demo to only Read access.
- Conversely, if Marketing has user Ann with all access rights, and the subitem has user Ann with only Read access, Apply Settings for all subitems gives user Ann all access rights on the subitem.
Removing a user or group from the access rights list
To remove a user or group from the access list, clear all of the access rights for that user or group and click Save.
Visitor groups are used by the personalization feature, and you need administration access rights to manage visitor groups. If you want an editor to manage visitor groups without providing access to the entire admin view, you can make the editor a member of VisitorGroupAdmins. This group provides access only to the Visitor Groups option in the top menu. VisitorGroupAdmins comes with Episerver but you must add it through admin view > Admin tab > Access Rights > Administer Groups > Add > VisitorGroupAdmins.
You can set specific access rights for visitor groups, letting them view specific "hidden" content that is not otherwise publicly available. For example, you may want only members of the Visitors from London visitor group to have access to a Family day at the zoo page with a discount coupon.
This feature is useful if you want to create a "customer area" for registered customers on your website. Being a member of a visitor group requires a registration and login to access the content.
- Go to the admin view > Admin tab > Access Rights >Set Access Rights.
- Select a node in the content tree.
- Click Add Users/Groups.
- In the Type drop-down list, select Visitor groups and click Search while leaving the Name field blank to view available visitor groups.
- Double-click a visitor group to move it to the Add box. Click OK.
Visitor groups can have read access only.
If your website has content in multiple languages, you can define access rights for languages so editors can create content only in languages to which they have access. Enabled languages are displayed in the Sites tab, but only users with access rights to a language can create and edit content in that language. See Managing website languages.
Access rights for the Episerver platform
See Managing permissions for more information about how to manage access rights for other parts of the Episerver platform.