Table of Contents
Overview
Viewing Roles
Adding Roles
Future Actions
Downstream Implications of RBAC Changes for End Users
Hard-Coded Logic
Related Articles
Overview
Coursedog allows institutions to define user roles by customizing permissions.
These Role Based Access Control (RBAC) permissions dictate what users are able to see and do in the platform. For example, a Department Scheduler should have different access than an Administrator in the Registrar's Office.
Coursedog comes pre-built with a variety of roles but offers flexibility around editing these roles and adding additional custom roles.
When you have a user who needs different permission settings for different products, it is best practice to create a custom role for them, rather than to assign multiple roles.
The pre-built Department Scheduler and Instructor roles have pre-defined dashboards that will not update despite changes to permissions. Consequently, the instructor dashboard has been discontinued for most institutions.
A list of all role permissions and their implications can be found here.
Viewing Roles
Overview
PATH: Scheduling > Settings > Roles
Five roles come pre-loaded in Coursedog: Super Admin, Admin, Department Scheduler, Instructor, and Staff.
You may view and edit permissions for each role by clicking on the various toggles next to each role name.
Unless your institution is using the Instructor Dashboard, you likely do not need to use the Instructor role.
For an outline of these predefined roles and their permissions in Coursedog, click here. We recommend downloading this spreadsheet and using it as a tool to visualize and collaborate on roles.
Adding Roles
Overview | Permission Options | Conditional Permissions | Custom Roles v. Pre-Built Roles
Overview
If your institution needs to add a new role, you can do so by navigating to “+ Add Role” under the “Roles” tab. Each configurable role allows or limits editing access to Coursedog functionality across the platform in each of the modules (Course Editor, Preference Forms, Instructor Dashboard, Rooms, Buildings, Reports, Institution Settings, Optimizer, Relationships, and Rollovers).
Permission Options
Permissions for each functionality in each module can be set to “Allow” or “Deny”. Certain permissions additionally have an “Allow If” statement which is followed by a condition, as seen below.
Conditional Permissions
Overview | Allowed Terms | Custom Conditions
Overview
If you set a permission to “Allow If” and leave the conditions field blank, this is equivalent to having the permission set to “Allow”.
The available “Allow If” parameters are “User is assigned to department”, “Term is not historical”, “Term is current scheduling term”, and “Allowed terms”.
Additionally, “Custom conditions” can be built for the “Edit Sections” permission, and “'User can edit section” can dictate when a role is able to delete sections.
Allowed Terms
Allowed terms allows you to make role-based access control term-specific.
Custom Conditions
Custom conditions allow you to build filters dictating when editing a section is permissible.
Custom Roles v. Pre-Built Roles
You will see a difference between Custom Roles you create and the Pre-Built Department Scheduler Role.
Pre-built roles have custom views of the left-navigation. For example, you may notice the pre-built Department Scheduler role will not see an “Optimizer” module on the left nav bar. Custom roles, on the other hand, will always display the standard (comprehensive) list of modules on the left nav bar.
RBAC allows for permission restrictions to be enforced. For example, if you create a custom role and set the “Run Section Optimizer” permission to DENY, a user with that role will see the “Optimizer” module in the left nav bar (since this is a custom role) but will not be able to run the Section optimizer (given their permission set-up).
Future Actions
Overview | Adding a Future Action | Activating Future Actions | Deleting Future Actions
Overview
PATH: Scheduling > Settings > Roles > Future Actions (top right)
The Future Actions functionality in Academic Scheduling allows Administrators to change user permissions on a certain date, acting as a one-time trigger to change the permission settings in the Coursedog system.
Possible use cases include cutting off access to section editing on a certain date or granting access to the editor at the start of term scheduling. However, note that if you wish to temporarily change role permissions for a certain timeframe, best practice is to set that up in phases and then assign the applicable phase to your Future Action(s). You can learn more about creating phases here.
Adding a Future Action
Step 1: Select the “+ Future Actions” button.
Step 2: Input a name for your future action.
Step 3:
Input the date you would like for the future action to kick in.
Once the send date arrives, the roles are set until manually changed under Roles or until another phase or future action updates them.
After the "Send Date" has passed, the future action no longer has any functionality. For instance, changing the permissions in a future action that has already occurred does not undo the role change.
If you change the "Send Date" of a future action that has already occurred, this does not undo the role change; it simply adds a new trigger to update permissions on the new send date.
Step 4:
If you would like for impacted roles to receive an email notifying them of a permission change on the send date, set the “Send Email” toggle to “Yes” and proceed to Step 5.
If you would prefer to not send an email, skip to Step 8.
Step 5: Input an email subject (the default is “Coursedog Future Action”).
Step 6: Type the body of your email into the WYSIWYG editor.
Step 7:
In the “email recipients field”, select the roles you would like to receive the email.
If no roles are specified, the email will not be sent.
The notification will be sent to all users with the specified Role, regardless of product association. For example, if you detail “Admins” should be Email Recipients, then any user with the “Admin” role will receive this notification (even those that may only have access to other products like Events, Curriculum, or Catalog Management). If needed, one workaround for this would be to create a product-specific custom role wherein permissions for all other products are set to “deny” (you will want to work with your Customer Success representative to validate the custom roles and ensure users have appropriate access).
Step 8:
Consider which term(s) the future action is associated with, and select those from the “Display Terms” dropdown menu.
Future actions are typically specific to each term, since key scheduling dates will vary each term.
This will impact which terms the timeline should display for.
For example, if you only select “Spring 2022” here, Fall 2021 will not display the timeline.
Steps 9-10 (NOT RECOMMENDED):
Although it is an option, we advise against adding “roles” and “permission to change” here.
- We advise against this option because future actions have to be recreated every term whereas phases can be reused. Additionally, if role permissions are set up directly under Future Actions rather than within a phase, they affect the roles at a global level and will not revert back after a certain timeframe. For that functionality, you will want to create phases and then ADD those phases to Future Actions.
- Best practice is to skip to Step 11.
Step 11:
Click “Add phase to change”.
Select the relevant term from the “Select Term” dropdown and the proper phase from the “Select Phase” dropdown.
If you haven’t already created your phase(s), you can learn how to do that here.
Step 12: Click “Add Action”.
Activating Future Actions
Future actions will activate between 12-12:30 a.m. PST on the designated date.
They will only update when the page is reloaded.
If a user does not close their browser, they will not see the change until midnight when the page automatically reloads.
Please include a 24 hour buffer into your future actions to ensure all users see the change on the designated date (or ensure all users reload their browser).
Deleting Future Actions
Only users with the appropriate permission may modify or delete Future Actions up until they are executed.
When a Future Action is executed on the Send Date, the option to delete the Future Action is removed.
If you have the appropriate permission and wish to delete a Future Action, simply open the Future Action you wish to delete and select “delete future action” from the lower left-hand corner.
Able to Delete
The below image shows a Future Action scheduled to send in the future. It is editable and can be deleted because it has not been executed.
Unable to Delete
Once a Future Action is executed, you will no longer have the option to delete the entry as shown below. The action is stored for historical purposes.
Hard-Coded Logic
There is some hard-coded logic in Coursedog that is tied to prebuilt roles.
Page Visibility by Role
The below table breaks down what the Academic Scheduling product looks like for prebuilt roles on a role-by-role basis.
Anything with a checkmark is visible by the listed role; if there isn’t a checkmark, that means the prebuilt role cannot view the page in question even if you try to configure related settings to “Allow”.
Downstream Implications of RBAC Changes for End Users
It’s important to understand the implications of changing Role Based Access Control (RBAC) permission settings for users who are currently navigating the platform while those edits are made. In short, role setting changes relating to permissions do not take effect in real-time. Any changes to role permissions require a browser refresh in order for such permission edits to take effect for end users. For example, if a particular role initially was allowed to add sections and a user with that role were navigating the platform while you removed the role's access to add sections, the end user would not be faced with that new restriction until they refreshed their browser.
In order to avoid end users continuing to operate under an outdated set of permissions after you have made edits, you should either:
Prompt all users to refresh their browser after you have changed role permissions, or
Not allow access to the platform for 24-hours after your changes have been made (this will result in Coursedog forcing a timeout, which will consequently require a browser refresh when users log in again)