Built In System Roles of mojoPortal CMS (cannot be deleted, except as noted below)

Administrators

Users in this role can do anything in the site regardless of other permission settings. In other words, when specifying allowed roles, it does not matter whether you check the box for this role; users in this role will have permissions regardless of the settings. So in general you do not need to check the box for Administrators in view and edit permissions, and users in this role do not need to be added to any other roles. Special permissions granted by this role are:

• Add, edit, and delete user-defined roles.
• Add and delete users from roles.
• Create users outside of site registration. By default only Administrators can do this, but other roles can be designated using the "Roles that can manage users" setting in Site Settings, Security, Permissions (see below).
• Change site security settings like authentication settings, LDAP, password format, etc.

Note: To specify this role within the web.config or other configuration files, use "Admins".

Content Administrators

Users in this role can view and edit any page in the site, regardless of permission settings on that page. The only exceptions are pages that have Administrators as the only role selected. In other words, if you explicitly set a page's view/edit permission to Administrators only (no other roles selected), then members of Content Administrators cannot edit/view it either. In general you never need to check the box for Content Administrators in view and edit permissions, since they have these permissions intrinsically, and users in this role should not need to be in other roles. Special permissions granted by this role:

• Add or remove pages anywhere in the site.
• Edit any page or module regardless of permission settings (except as noted above).
• Designate which other roles can View/Edit a page.
• Change site settings, except security settings

Newsletter Administrators

Users in this role can manage and send newsletters.

Role Administrators

Users in this role can create and delete roles (except the protected system roles) and can add or remove users from any roles, except Administrators.

Note: To specify this role within the web.config or other configuration files, use "Role Admins".

All Users

You will see a role named "All Users" in places where you can assign permissions. This is not truly a role but a pseudo role. When you allow "All Users" to view pages that means the user does not have to be in any roles and does not even have to be authenticated (signed into the site) in order to view the page. This is to allow public facing pages for anonymous visitors on the internet. Real roles can only apply when a user is signed into your site, then we know who they are and can set their role cookie, whereas unauthenticated users have no authentication cookie and no role cookie and they are anonymous.

Authenticated Users

Users are automatically added to this role, but can be removed from it. This role provides a method to identify all users who are authenticated (signed into the site). Pages or modules can be hidden from anonymous users by deselecting All Users and selecting Authenticated Users in the Roles Allowed to View. 

Additional and User-Defined Roles (can be created/deleted)

You can create as many roles as you need, and grant the various page and module permissions to these roles on a page-by-page or module-by-module basis. This will give you as much granular control as you need over content management.  As an example, you could create a root menu page corresponding to each department in your company, then create a role for each department. Add a department's role to its page, granting it Page Edit and Create Child Pages permissions. Add the role to a user, and that will give them edit permissions on the root level page as well as any pages they choose to create beneath it forming a menu tree.

mojoPortal CMS delivers the sample roles Content Authors and Content Publishers when a site is created. These are not system roles, and have no special permissions other than what you grant to them. They can be deleted.

In general you should think carefully when designing your role structure. You can create as many roles as you'd like, but each user should be in no more than a handful of roles. A user's roles are stored in an encrypted browser cookie, and a cookie can only hold so much data. So if a user is a member of too many roles it can overflow the capacity of the cookie.

Permissions

Page View

Assigned by role on per-page basis, this enforces what pages users in that role can view, and what pages are seen in the menu. If set to All Users (as by default), anonymous (unauthenticated) users are allowed to view the page. This setting is enforced at the page level, so that even if a user changes the URL to navigate directly to a page, it will not be displayed if they are not in the proper role.

Page Edit

Assigned by role on a per-page basis. For each page on which users are granted this permission, they can:

• Add, move, or remove modules
• Edit page settings (except for permissions)
• Edit settings and content for any module contained on a page

Create Child Pages

Assigned by role on per-page basis, this works in conjuntion with Page Edit permission. On pages for which they are granted both Page Edit and Create Child Pages, users can create new pages below that page. Newly created child pages default to the same role permissions as the parent page, but this can be changed by Content Administrator or Administrator.

Module Edit

Assigned by role on a per-module basis. Users with this permission can do the following:

• Edit the content of the module, if they have at least View permission on the containing page.
• Edit module settings, except for security permissions.

Module Edit inherits Page Edit permission. In other words, if you have Page Edit permission, you don't need module edit permission.

Module View

Modules inherit the view permissions of the page they are on, unless overridden. So if a user is in the roles that are allowed to view a page, then by default that user is also able to view the modules on the page. But if the user is not in roles that are allowed to view a module, then that module will be hidden from the user viewing the page.

Other Permissions

There are a number of settings that grant special permissions to user-defined roles. These can be found under Administration > Site Settings > Security > Permissions:

• Roles that can create root level pages - Users in these roles can create pages that will appear as part of the site main menu.
• Roles that can browse and upload files - See Allowing Users to Upload and Browse Files for more information.
• Roles that can browse and upload but only in a user specific folder - See Allowing Users to Upload and Browse Files for more information.
• Roles that can delete files using the file browser in the editor - See Allowing Users to Upload and Browse Files for more information.
• Roles that can manage skins - Users in these roles can update and manage site/user/page skins.
• Roles that can edit content and style templates - Users in these roles can maintain the site's list of content templates and style templates.
• Roles NOT allowed to edit feature settings - By default, users with edit access to a feature are also granted access to change that feature's settings. Users in these roles will not be able to change settings even if they can edit a feature.
• Roles that can lookup users - Users in these roles can look up users and view user email addresses. This is used in a particular lookup user dialog box used in some features, notably the Web Store feature.
• Roles that can create users - Users in these roles can create new users, but do not have permission to manage users after they are created.
• Roles that can manage users - Users in these roles can fully manage users, except for users in the Administrators role, and they cannot edit user roles unless they are also in the Role Managers role.
• Roles that can view the member list page - Users in these roles can view the member list page. By default, users in the Authenticated Users role are allowed to view the member list, so this provides a method to hide the member list from signed in users.
• Roles that can use the My Page feature - Users in these roles can use the My Page feature, if My Page is enabled. By default, users in the All Users role are allowed to use My Page, so this provides a method to prevent use of My Page except by users in certain roles.

Managing User Roles

You can add and remove roles for a user by looking up the user in the Member List, and selecting Manage. You can also mange roles and role membership from Administration > Role Administration. Note however that when you add a user to a role, the user will need to sign out and sign in again in order to get the new encrypted role token in his cookie.

Renaming Roles

Roles have both an internal Role Name and a Display Name. At the time a role is created these are both the same, but if you change a role's name you are really only editing the Display name. This means you can, for example, rename the Administrators role for localization without breaking anything, because the underlying role name stored by the system is not changed. For user-defined roles, if you really wanted to change the underlying role name and not just the display name, then you would have to delete the role and re-create it using the new name so that both role name and display name match.