Access rights

By using access rights in Optimizely Content Management System (CMS), you can control the content visitors see, 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 application 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 panels.

Access rights are normally managed from the administration view in CMS, but you can give editors the right to manage access rights for a single page in edit view.

Access to features

Different parts of the Optimizely platform have different built-in roles and groups used to control authentication and authorization on a granular level. Developers usually set up permissions during implementation and service onboarding. You need to have administrator access to configure access rights in Optimizely.

You can switch among products by using the product switcher. Parts of the platform may also be accessed through a specific URL.

What you see in the side menu of CMS (SaaS) when logged in depends on which product you have selected and your permissions. During onboarding and set up of CMS (SaaS), the side menu is configured, and access rights are defined for different user groups. See Get started with CMS (SaaS) for details about the side menu.

Access to content

You can control which parts of the application content structure should be available to all visitors and which parts should only have restricted access to logged-in users. You can also let visitors post comments on the application through access rights.

Built-in user groups

Optimizely CMS has built-in user groups that align with user roles. When you set up a application during development, configure the membership and role providers available for your application to use the built-in groups and roles in Optimizely.

• Administrators – Windows defines this group when the application is created. An administrator can access all parts of the system and can edit all application content. Often, administrators are developers who set up or maintain the application.
• Everyone – Windows defines this group to give visitors read access to application content. Unregistered visitors to a public application are anonymous, meaning the system cannot identify them. If you want to remove the Everyone group from content (to change access rights for a web page, for example), you must login to access content, even if it is published.
• CmsAdmins – Optimizely defines this group to access admin and edit views. Membership in this group does not provide editing access to the content structure. In most cases, only a few system administrators or "super users" belong to this group.
• CmsEditors – Optimizely defines this group to access the editing view. Add users to this group who need access to the edit view. Then, add the users to other groups to give them specific editing rights to content. On large applications, editors are often organized in groups according to content structure or language.

Types of access

You can grant or deny access to users and groups:

• 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 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) 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 the admin view. To access the admin view, you must be a member of the WebAdmins group (see Built-in user groups).

Set access rights from Settings

You can apply access rights to assets in the content structure from the Root level and down, including the Recycle bin (Trash), and For All Applications that store blocks and media. (Blocks and media share the same folder structure.)

1. Go to Settings > Access Rights >  Set Access Rights. The Set Access Rights page displays with a content tree structure of the application.
2. Click a node in the content tree. Typically, a content item shows Administrators (with all access rights) and Everyone (with Read-only access rights). You can change these rights or add 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 checkbox.
   • To add settings to the selected node's subitems without affecting their existing settings, select the Apply settings for all subitems; see section Set access rights for all subitems below.

     

3. Select Add User/Group and select a user or group from the list. You can enter a name or email address in the search field to find a specific user or group. In this example, the Authenticated group is selected.

   

Set inheritance for content subitems

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 subitems that have enabled the Inherit settings from parent item option; subitems with this option cleared are not affected. For example, Addresses, Cards, Dictionaries, Mosey Bank Footer, and Mosey Bank Header have the same access rights because they inherit the access rights from the Content page.

If you break the inheritance for Cards and change its access rights, the access rights become different from the parent (Content) and its two siblings (Addresses and Dictionaries). An example of this is shown in Set access rights from edit view.

Set access rights for subitems

Selecting the Apply settings for all subitems checkbox applies the access rights of the parent item to its subitems, even if a subitem has inheritance cleared. The option adds settings to a subitem it did not have before and does not change or remove any existing settings. For example, you can apply the same access rights from the Content parent page to its children (Addresses, Cards, Dictionaries, Mosey Bank Footer, and Mosey Bank Header).

When you select Apply settings for all subitems, anyone who is part of a selected group is given access.

Suppose 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. In that case, the parent's settings are applied when you select Apply Settings for all subitems. For example:

• If the Content parent item has user Abbie with only Read access set, and Mosey Bank Header subitem has user Abbie with all access rights set, then Apply Settings for all subitems on the Content parent item resets Abbie's access rights on Mosey Bank Header to Read access only.
• Conversely, suppose Content has user Abbie with all access rights, and subitems have user Abbie with only Read access. In that case, Apply Settings for all subitems gives user Abbie all access rights on the subitems.

Set access rights from edit view

Administrators generally manage application access rights from the Settings view. However, you can set access rights for a single page or a block from the edit view if you have administrator rights. This is useful when you need to publish an item to verify the final result but you do not want it to be publicly visible.

The following example shows how to set additional access rights to (1) the Mosey Bank item (and its subitems) and then set different access to (2) the Insights item and its subitems).

1. Select Mosey Bank in the content tree.
2. In All Properties view, click Manage in the Visible to field.

   

   The Access Rights page displays.

   

3. If access rights are inherited from the parent page, clear Inherit access rights from parent item. You can now edit the access rights.

   

4. Select Add User/Groups to add a group, application, or user to the access rights list. In this example, add the Authenticated group.

   

5. Set the access rights you want, and click Save. In this example, the Authenticated group was given Read, Create, Change, and Publish rights, but they cannot delete or administer any of the content in the Mosey Bank content tree.

   

6. Select Insights in the content tree, and click Manage in the Visible to field (in All Properties view).

   

   The Authenticated group was inherited.

   

7. Clear Inherit settings from parent item to edit the Authenticated group's access rights.
8. Clear the settings for the Authenticated group and click Save.

   

9. Click Manage in the Visible to field (in All Properties view) to verify that the Authenticated group was removed from the Insights access rights.
10. Go to Insights subitems (Giving Back, Financial Services..., and How to: Use AI...) and click Manage to verify that the Authenticated group was removed from the access rights of those subitems.

    The Authenticated group was given specific access to all items in Mosey Bank except for Insights and its subitems.

Set access rights for media

An editor must have Create access rights to the global or application-specific folder under For All Applications or For This Application to upload an image or create a block. Similarly, an editor must have Create access rights to the current page when adding assets to the local For This Page folder. 

Media are never automatically published if someone sets an approval sequence on the folder to which the media are uploaded.

Suppose you want media to be automatically published when it is uploaded. In that case, editors who upload must have Publish access rights to the global folder, application-specific folder, or the page if media are uploaded to the local folder. See Folders for a description of global, application-specific, and local folders. 

Should I set access rights for a single user or a group?

You can set access rights to content for a single user. For example, you can set the access rights so only Abbie (and system administrators) can edit the Book a Demo page. You can add Abbie to any number of pages and content and set Abbie's access rights to each content item the same (or differently) for each page.

If you have several users who need common access to content, managing access rights on a user-by-user basis can be complex. Create roles with similar access needs, add the users to each role, and then use the role to set access rights to content. This lets you manage access rights. You can add a user to one or more roles.

For example, add Abbie, Erin, and Reid to a Marketing user group and give access rights to any number of pages and content to the Marketing group instead of each individual. You modify the Marketing user group to add Eddie to all of the Marketing content (or remove Abbie). You do not have to visit each page or content item to update users' access rights.

Remove 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 Access Rights.

Access rights for languages

If your application 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. Go to Settings > Config > Languages to see enabled languages, but only users with access rights to a language can create and edit content in that language. See Manage languages.