Managing Page and Context Permissions

This chapter explains how permissions are managed.

Key Concepts of Managing Page and Context Permissions

To give privileges to your users, you assign them to roles, and they inherit the privileges associated with those roles.

Automatically Assigned Privileges

In some cases, roles are automatically associated with privileges. For example, in the default setup of the portal, the following are true:

Members of the Administrators role by default have all privileges. It is not possible to take away these privileges.
Members of the Faculty role have the Can Admin privilege in the Academics context.
Members of the Students role can view several pages of the contexts for course sections in which they are enrolled.
In the Forums feature, by default, members of the Users role can publish posts and reply to posts.

Manually Assigned Privileges

This chapter describes the privileges that you may want to grant to the various roles, including permission to do the following:

View pages
View tabs
View links to subsections
Manage tabs and contexts
View and manage features, or to take specific actions within features
Administer pages

Letting a Role View Pages and Context Links

You can control users’ access to pages and contexts as follows:

You can set up pages so that only members of certain roles can view and use them.
Depending on how you set up pages, you can also manage whether the links to subsections and tab icons are displayed to the various roles.

This section describes these processes.

Letting Roles Display Subsection Icons and Tabs

You cannot manually manage the display of tabs, or of subsection icons within the sidebar. This access is managed dynamically by the system and is based on permissions settings for child pages of the tabs and subsections. Access is determined by the following rules:

A tab is displayed only for roles with permission to view a child page.
If a role has permission to view one or more of the child pages in a tab—that is, direct child pages of the tab, not pages within a child subsection—the role also has permission to view the tab itself. Conversely, if the role does not have permission to view any of the direct child pages within a tab, that tab will not be displayed for them. It doesn’t matter whether the role has permission to view child pages of the tab’s child subsections.

So, for example, if a tab has one child page called Home, and a subsection with a default page called Welcome, the role must have access to Home or the tab will not be displayed. It does not matter whether the user has access to Welcome.

Note that if your system is set up so that users have permission to view pages within a tab’s subsections, but none that would allow the tab to be displayed, you must set up an alternate method of navigation for these users to access the pages that they are allowed to access.
Two types of permission are required for a role to display a subsection icon.
The following two things must happen for a role to be able to display a subsection icon in a tab’s sidebar:
- The role must have permission to display the parent tab, as described in the previous bullet point.
- The role must have permission to view to one or more of the subsection’s child pages.
If you grant the role permission to view the subsection’s child pages without giving them permission to view the tab, you’ll have to set up an alternate method of navigation for these users to access the pages that they are allowed to access.
A role’s permissions settings can affect the default page they see.
The way you set up permissions for a role can affect the default page that those users see for a tab or subsection.
If you give a role permission to view a page within a tab (or subsection), but you do not give that role permission to view the context’s default page, then the system will automatically display whichever permitted page is listed first in the sidebar.

Managing Feature Permissions

Managing access to features is done in the following ways:

You can make sitewide decisions via Site Manager. These permissions are global—they affect every instance of the feature. The different permissions vary by feature and are covered in the Managing Global Feature Operations section.
You can set permissions for individual feature instances. Depending on the type of feature, this can give the roles a wide variety of different privileges. The different permissions vary by feature and are covered in the chapters that deal with individual features in Part 2, “Working with the base features.”
If you want a role to have the administrative privileges available through the admin bar—including the Access and Settings pages, you must give the role administrative privileges in the context, as described in Allow a Role to Administer a Context.

Procedures for Giving Permissions to Roles

Allow a Role to View Pages

You may have pages in your portal that should be viewable by some roles, but not others. For example, you might have a series of pages intended only for your teaching assistants. You would manage this by creating a Teaching Assistants role and granting it access to the page.

Your setup for each page has an effect on whether the links to subsections and tabs show up for the different roles. For details, see the Letting Roles Display Subsection Icons and Tabs section.

To let a role view a page:

Log in to the portal as a member of the Administrators role or someone with Can Admin privileges in the appropriate context. Navigate to the page for which you want to set permissions.
Click the wrench icon in the upper-right corner of the page.
The admin bar displays.
Click the Access link in the admin bar.
The system displays the Access page, which lists all the roles defined for this context as well as all the global roles. Roles that have access to the page are highlighted in green. Roles that do not have access to the page are shaded gray.
Click the role to which you want to give permission to view the page.
The system displays a dialog asking you to verify that the page is meant (and ready) to be viewed by the selected role.
Click the Hidden button to change it to Visible.
Now that the role can view the page, the screen refreshes to list the permissions available in each of the features found on the page. For information on managing feature permissions, see the Managing Feature Permissions section.

Allow a Role to Administer a Context

In some cases you might need to give members of a particular role permission to manage a tab or a subsection. To achieve this, you grant that role the Can Admin privilege for the appropriate context. Roles with this privilege will have access to the admin bar that appears when you click the wrench icon at the top of most pages within the portal.

Wrench icon at the top of most pages within Portal

When you give a role this permission, members of the role are allowed to do the following:

Display any direct child pages in the context. For example, if you grant a role the Can Admin privilege for a course context, the role can view all the pages that are direct “children” of the context, such as Attendance and Coursework.
Display and administer all pages on all child contexts of the context, if any exist. For example, if you grant a role the Can Admin privilege for a course context, then that role is automatically granted the Can Admin privilege in all of the child contexts.
Add pages (both directly to the context and to any child contexts).
Edit any existing pages.
Add subsections.
Administer existing subsections.
View and administer all feature instances in the context. This includes having access to the admin bar for all feature instances.
Give permission to other roles to view and administer the tab or subsection (as well as remove the permission).

To give users permission to administer a context:

Log in to the portal as a member of the Administrators role or someone with Can Admin privileges in the appropriate context. Navigate to the page for which you want to set permissions.
Click Context Manager.
The system displays the Context Manager screen, with the Properties tab selected by default.
Click the Permissions tab.
The system displays the Permissions screen, which lists all the roles in the system on the right and the permissions for the currently selected role on the left. The Context admin permission is listed first, followed by permissions for each of the pages in the context.
From the list of roles on the right, select the role to which you want to grant administrative access.
Permissions for the selected role display on the left. (If the Yes button in the Context admin box is green, that means the role is already an administrator for the context, and no further action is needed.)
In the box labeled Context admin, click Yes. The button turns green to indicate that the role is now an administrator for the context. Note that when you select Yes, the system automatically gives the role Can admin privileges to all the pages in the context (if the role does not already have them).

Allow a Role to Administer a Page

In some cases you might need to give members of a particular role permission to manage a page. To achieve this, you grant that role administrator privileges from the Access screen.