Child pages
  • Student View
Skip to end of metadata
Go to start of metadata


Draft Mode- this is a mish mash of emails and still needs review and refinement. I just wanted to get something up

Work for 2.5 completed in following branches:

Brief Overview

A new permission, "site.roleswap", is set for particular roles in any given site (database). The permission will determine if the role swapping capability is to display on the site. Additionally, in the configuration file, a property named "studentview.roles" is defined and tells the application which roles can be switched to.

Assuming the permission above is set for the user's role for a site, a url link or a drop down menu (depending if there's 1 or more roles in a site that may be switched to) will display in the upper right. The user simply clicks the link or picks which role they wish to switch to. The user will be taken to the front page of the tool they were in with an updated display of what the page looks like to the role selected. This state will remain for other tools in the site, as well. There will be a hyperlink saying "Exit (role name) View" where the link/drop down menu was prior. The user clicks on the link to return to their normal role and the page display will return to what it should normally be for the user. Should be noted that since the variable is unique, the state will not cross over to other sites a user may be part of.

In the background, after a user selects a different role, a unique variable is set in the session that will be checked on frequently in the authz tool, especially the "isAllowed()" functions. If this variable is found in authz, a different query is ran against the database to make sure the permission is exists in a site and return the appropriate true/false answer on the function. When the user exits the role swap view, logs out, or closes the browser, the session variable is deleted and will be back to a normal state.

Tool Breakdown


The site tool is used to register the "site.roleswap" role with the system, especially in tools where roles may be set, such as the Worksite Setup tool for administrators. It is also used to create a function called "allowRoleSwap(siteId)" that will look up if the role exists for a user in a site via SiteService. This call is used specifically in the portal tool. The modifications for site are fairly straight forward.


The portal tool handles the logic to check if there should be a role swapping component to be displayed in the UI and handles setting and unsetting of a unique session variable. The session variable is handled by two "handler" files, and The session variable is handled in the following format, Name: roleswap/site/
{the site id}
Value: the name of the role the user picked to switch to. This variable is critical in both the portal tool and the multiple places on the authz tool. Other than setting and unsetting the session variable, the portal logic determines if the user is in a normal state or a swapped state and will display the appropriate component in the UI.

This tool does the bulk of the work. Authz normally handles most of the "isAllowed()" calls throughout sakai, so checks for the session variable are placed inside these functions as well as a "checkAuthzGroups()" function.

In the "isAllowed()" functions, if it successfully finds the session variable for the site, it will call some alternate SQL through the SAKAI_REALM_RL_FN table or may simple for the return variable to be a certain value, in special cases like Forums that look up a specific user role and doesn't use authz the same way most other tools do. This table is normally used to determine which roles are defined in a site for a particular role and serves as a perfect check if the user is pretending to be a certain role. This will return an appropriate true/false answer for whatever tool is calling the isAllowed function.

Very Brief Summation
• Roles in a site that can use the role swapping functionality have the "site.roleswap" permission defined
• Roles that can be switched to are defined in by "studentview.roles"
• User clicks a link or drop down item for the role they want to switch to
• Portal code does the checking to make sure its a legit request and sets a unique session variable to the site
• Authz checks for this session variable in various places (other tools can too, if needed, such as Forums) and runs some alternate code to make authentic permission checks for whatever role the user is wishing to imitate
• Clicking the exit link gets rid of the sessionvariable and everything goes back into a normal state

  • No labels

1 Comment

  1. We've just discovered that if users are members of the admin workspace, they will not be able to see the drop down in the UI, which makes it difficult to verify for configuration/testing purposes. I'm wondering if this was by design, conscious or unconscious. Does anyone know?