|
r38916 & r38917
First attempt at this. Separated it out to a different branch for now to get some testing from IU and make changes on it before moving it into trunk. Feedback and fixes are certainly welcomed! r38924 - edit for a 2.4.x build
2.4.x version:
authz - r38992 portal - r38993 site - r38994 trunk version: site - r39014 portal - r39015 authz - r39016 Greg, is there a design or spec that you could post here to describe this new feature and give folks an idea of how it works? Thanks.
View of before a user selects a role. All roles available in the site (except the user's current role) are displayed in the dropdown.
View of the page after a different role has been selected.
A new permission, "site.roleswap", is set for particular roles in any given site. The permission will determine if the role swapping capability is to display on the site.
Assuming the permission is set for the user's role for a site, a drop down menu with all the roles available in the site (except the user's current role) will display in the upper right. The user simply picks which role they wish to switch to. The user will be taken right back to the tool/page 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 Swap View" where the 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. The branches were updated to get the newer versions of the various trunk codes. Committed some more updates based on that.
authz - r41596 portal - r41597 site - r41598 sakai-mock - r41599 Update on this:
The roles that can be switched to with this tool are now defined in sakai.properties so institutions can set them to whatever they want them to be (e.g. studentview.roles=Student,access ). This is not to be confused with roles that have permission to use the role switching mechanism. The UI will know if there's multiple roles for the site and will display a dropdown for the user to select which role to switch to or if its only 1 role, it'll be a standard anchor link. Because of that change, that also makes the security a bit tighter and various checks are made throughout the code for sanity purposes. This helps ensure the system gets legit requests that an institution wants to allow. Additionally, the caching is much more efficient now in the authz tool, so it should increase performance. Attached 2 patch files, 1 for the kernel part for 2.6 and the other for the rest of the code.
Also attached the change to put in sakai.properties as well as the backfill sql. Note on the backfill that you'll need to edit it first depending if you're doing mysql or oracle. Some comments.
The Kernel Patch is Ok. Can you confirm that there is an audit event when an a role is switched. Where is a UI to switch roles ? Is it on or off by default ? I guess it isn't clear in the comments, so I'll try to clarify it better. :)
1. Run the SQL script (edit it first to uncomment and pick for mysql or oracle). The site.roleswap permission is given to Instructor for course and project sites by default. 2. Edit your sakai.properties and add in the content from the attached file (sak-7924-sakaiproperties.txt). Defaults are set to Student, Teaching Assistant, and access. 3. Apply both patches to your instance. If those all all done, you should be good to go. It is on by default. If the user has the site.roleswap permission and a role from the sakai.properties is found in the site, then something (link or dropdown) will render in the UI in the upper-right part of the screen. I guess you can easily turn this feature off on the site just by simply not having anything defined in the sakai.properties or having nothing with the site.roleswap permission. From the UI and assuming you have the permission, there will either be a link that says "Enter (role name) view" or a dropdown with "View Site as: (dropdown with available roles)". After clicking the link or picking something from the drop down, the link will say "Exit (role name) view". Additionally, the tool that you are in will be reloaded onto the 'home page' of that tool and refreshed into whatever role you picked. You'll stay in this role throughout the site until you either logoff or click the exit link. This event is tracked through variables in the session (which can be viewed in the portal section of the code). Its the key for triggering permission checks to check as a different role for what the user should be. This ensures the "swapped state" is only for a particular site for the user and can easily expire just from closing the browser and preventing any sort of weirdness the next time the user logs in. Hopefully this will make it more clear. Feel free to edit the various roles to try out different combinations. Its suppose to be flexible in that regard. [Bulk Comment] This Task (or Sub-Task) issue currently is Unresolved, but has a Fix Version of 2.6. The Code Freeze for Sakai 2.6 has now passed (29-Sep-2008, 8:00am Eastern US time).
If you are still working to resolve this issue for 2.6, then please post an email to sakai-dev to let everyone now that you need an exception for this JIra, explain what is left to do, and when you plan to have the work completed; please include that information here in the Jira as well. Otherwise, if the resolution of this task has been postponed, please reset the Fix Version to 2.7 or Unknown, depending on what you're new expectations for completion are. If the issue is no longer relevant, please close the issue as Won't Fix or Incomplete with an explanation of why. Thanks! This should be resolved now with all the code in the trunk build. Just need to make sure it gets properly cut into 2.6.
Just checking in to see what the status if for this getting into the 2.6 release. Major issue for faculty here at Marist so we're hoping it makes it! Thanks for the effort on this one!
This will be in 2.6. There are a couple of related issues that have surfaced (see the linked issues above), but nothing too severe.
Just looking for confirmation at this is in 2.6???
We're starting our transition planning. It appears that users in the admin role (e.g. who are members of the Admin workspace) cannot see this change in UI. Does anyone know if there is a way to enable this or was this by design?
Currently, it's "by design" (though not optimal) because for admin users, all authorization checks are bypassed, so "student view" doesn't have any effect. To see it, you have to login as a regular user.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Task
Resolved
Blocker
View Site as if in a Different Role
An instructor wants to demo their site in class as if they were a student looking at things.
"Our instructors often want to demo their site to students live in class. They don't want hidden materials in the default view of the Resource list, even for them. A way to hide this column from the list view, even just during the session if not as a "Hide availability in list view" Option, would help. I can't imagine being an instructor on Day 1, standing up in front of class to show students what the resource area looks like with three available resources and 30 marked hidden!"