One of the great features of Princeton Site Builder is the ability to control how and what users can access on your site by assigning specific roles to them.
Users Dashboard
Site Admins can view a list of all users on their site by clicking the main Users item in the admin toolbar.
This dashboard shows a list of all user accounts on your site, sorted by the users that logged in most recently at the top.
Users Without a Role
Some sites may have a small or large number of user accounts that have no role. These users are displayed in the Users dashboard by default, but you can hide them by checking the Hide Princeton users lacking an assigned role for this website checkbox at the top of the dashboard and pressing the Filter button.
It may be that you do not recognize these users, and don't remember adding their accounts. The most common reason they appear is because someone with a Princeton Net ID attempted to access a Webform that is configured to require authentication. When someone attempts to access these protected webforms, it prompts to log in with their Net ID and will create a basic user account for them after authentication. This is just a side effect of how the access control system works. You do not need to be alarmed about these users. As long as they have no roles, they have no editorial access to your site.
Adding Users
- Log in to your website.
- From the administrative toolbar, select Manage > Users > Add CAS User(s)
- Enter their netID in the CAS username(s) box. You may enter more than one netID -- one per line. Do not enter full email address, enter only their netID.
- Select a role to assign to the users.
- Click Create new account(s).
Editing Existing Users
From the users dashboard (click Users in the admin toolbar), click Edit for the user you'd like to edit. You can use the search filters to help find an existing users.
When editing a user, you can modify their assigned roles and control if they receive site alert notifications.
If you just want to add or remove roles, you can also use the bulk selection checkboxes on the users dashboard and choose the appropriate action from the actions menu.
Removing Users
Instead of completely removing a user, it's typically better to block that user and remove their roles instead. If you really want to delete a user, find the user on the main Users page, click Edit, and then click Cancel User at the bottom of the form. Follow the instructions, but be careful not to select the option that deletes all the content the user created unless you're positive that's what you want to do.
If the user leaves the University and you do not take any action, they will automatically be logged out of the website after 6 hours of inactivity. They won't be able to log in again, and their content will continue to show as being owned by the user.
Standard User Roles & Permissions
Site Admin
Site Admins have the highest level of access to a Site Builder site (aside from WDS staff). People with this role can configure site information, enable optional modules, manage all content and webforms, manage all other users, and more.
This role includes all permissions that the Content Manager, Content Author, and Reader roles have, plus the following:
- Add custom CSS to enhance the design of their site
- Modify the patterns used for generating automatic URL aliases
- Enable and configure optional modules
- Create, edit, and delete users
- Modify theme settings
- Clear the website caches on-demand (rarely needed)
Content Manager
A Content Manager has complete control over content (other than Webforms) on the site.
This role includes all permissions that the Content Author and Reader roles have, plus the following:
- Create/edit/delete/publish/unpublish any content items
- View/delete/revert any content revisions
- Create/edit/delete all media, documents, and reusable custom blocks
- Create/edit/delete all menu items
- Create/edit/delete taxonomy terms
- Administer all URL aliases and URL redirects on the site
- Manage the footer content and layout
- Schedule news & events to be published
- Manage & review the results of the automated accessibility checker
Content Author
A Content Author is the most limited content authoring role.
In addition to the Reader role, this role can:
- Create new content items (News, Events, Pages, etc), but cannot publish them or create menu links for them
- Edit any published and unpublished content (but cannot unpublish existing content)
- View all revisions for existing content, but cannot revert to them or delete them
- Edit Layout for all Page content items
- Create new media and documents, but cannot edit or delete media and documents that they did not create
- Create new Webforms
- Edit, view submissions for, and delete their own Webforms
Reader
The reader role is highly limited. It's intended to be assigned to people to preview a site while it's in maintenance mode or to preview pages that are not yet published.
The reader role can:
- View/browse the site while it's in maintenance mode
- View all unpublished content
- If the Access Control A collection of features or functionality that can be enabled on sites. WDS has made several optional modules available to site administrators to enable on their site. For example, the "News" module enables the News content type and provide a News List Block for displaying news on a page. is enabled, they can view all private content
CSS Manager
The CSS Manager can only be applied to users by WDS. This role grants supplemental permissions to content managers and site admins for managing custom style definitions.
Webform Admin
The Webform Admin role is only available for sites that have enabled the Webforms module. This role grants full access to create, edit, and delete all webforms, including their submissions.
Webform Submission Viewer
The Webform Submission Viewer role is only available for sites that have enabled the Webforms module. This role grants access to view all webform submissions for all webforms, and nothing else.
Guest accounts
For a non-Princeton-affiliated person to access sites for editing purposes, it is recommended that Guest Account Provisioning (GAP) accounts be created so that passwords are maintained externally maintained.