A provisional tool is one which is considered to be mature enough to be included in the release distribution, but is not (yet)considered to be an official part of the enterprise bundle, and which does not come enabled by default. Additional manual steps are required to enable these additional tools, per the discretion of the deploying institutions or individuals.
The basic idea of a provisional release is to allow sites to test these new capabilities for a release before promoting them to be part of the official release. Your feedback on the suitability of these tools for inclusion in an upcoming Sakai release is an important part of this process.
You are encouraged to use these tools taking careful care to test them in your environment and with your users. Some of the tools can be partially enabled to give you a way to roll out the tools to a subset of the users on your system.
Full documentation of RWiki is available at: http://saffron.caret.cam.ac.uk/projects/sakai-rwiki/
By default, RWiki is included in the release but hidden from the list of available tools in the Worksite Setup. RWiki will be available to adminsitrators using the "Sites" adminsitration interface as one of the tools Wiki (sakai.rwiki). You have one of two choices in terms of enabling RWiki.
If you want to let a few selected users use RWiki to test it out, you can have the adminstrator selectively add it by hand to the sites for those users who you want to use RWiki.
If you want to make it so that any user can add Rwiki to their site using WorkSite Setup, edit webapps/sakai-rwiki/tools/sakai.rwiki.xml in a deployed instance, or rwiki/rwiki/src/webapp/tools/sakai.rwiki.xml in a source tree. Uncomment the
su is a tool for Sakai 2.1.x for administrators to use to log in as another user. It is code developed at Texas State University for their local brand of Sakai called TRACS: Teaching Research and Collaboration System. It is meant to be used within the Administrative Workspace. It features a simple form in which you type the user id of the user you wish to login as or "become" in the system.
The name stands for Super User, and comes from a command-line tool in Unix that serves the same purpose. It is often pronounced "Sue."
The su tool is part of the standard Sakai release. The tool is only available to adminstrators and not part of the Adminstrator Workspace by default. If you would like to completely remove the su tool, it is at the path /admin-tools/su in the Sakai source tree.
After the su tool is deployed, it will appear in the list of tools in the Administrative Sites tool. It will NOT appear in the list of tools for the Worksite Setup tool, since su is intended for administrators only, and not for general use.
In order to use the tool, use the Sites tool in the Administrative Workspace to edit the !admin site, add a page or edit an existing page, and place the tool on that page. The su tool will appear in the list with the title "Become User" and the id "sakai.su." When you've placed the tool, remember to click the Save button.
The tool itself is very simple. There is a text field to type a user id, and there is a Submit button. Your session will continue as though you had logged in as the specified user. This will work even if that user is already logged in at another location.
To change back to "yourself," you must logout and log back in.
The su tool is hard-coded only to work for users with administrative privileges. Naturally you should take care whom you give these privileges to. The ability to have more fine-grained control of permissions on the tool may be developed for a future version.
It's a small thing, but if you click the "View user info" button, the button should then become disabled unless the id field should change.
Sakai su is written by Zach Thomas at Texas State University. You may contact him at firstname.lastname@example.org.
Sakai 2.0 shipped with the capability to support web services, but with very few web service end points. Sakai 2.1 adds a number of Web Services end-points (SakaiScript). SakaiScript was led by Steven Githens and a number of developers in the Sakai community.
Sakai web services and SakaiScript are included in the release and need to be turned on using a property in the Sakai Properties file:
# Indicates whether or not we allow web-service logins webservices.allowlogin=false
This parameter is set to false so as to make sure that no one can robot-guess Sakai passwords using web services out of the box. If you want to support the login and session-establishment, you must set this proprty to true in your Sakai instance.
Any site enabling web-services should understand the security implications of Sakai web services. Web services should be run over HTTPS in any production environment as IDs, Passwords, and Sakai Session Keys are passed back and forth in plain text using SOAP. This is quite reasonable (and equivalent to how browser-based login and browser cookies work) but depends on HTTPS for protection of the materials contained in the SOAP envelope.
By default, Roster is included in the release but hidden from the list of available tools in the Worksite Setup. Roster will be available to adminsitrators using the "Sites" adminsitration interface as one of the tools Roster (sakai.site.roster). You have one of two choices in terms of enabling Roster.
If you want to let a few selected users use Roster to test it out, you can have the adminstrator selectively add it by hand to the sites for those users who you want to use Roster.
If you want to make it so that any user can add Roster to their site using WorkSite Setup, edit webapps/sakai-roster-tool/tools/sakai.site.roster.xml in a deployed instance, or roster/roster-app/src/webapp/tools/sakai.site.roster.xml in a source tree. Uncomment the
There is no standard way to provision the pictures in the Roster tool in this release, but there is sample code you can take as a model for creating your own photo load job, and you can find it on subversion:
If you would like further information on how to provision the pictures, contact Lance Speelmon (email@example.com).
TwinPeaks is a capability to search external repositories while using the WSYWIG editor. TwinPeaks was originally developed by the Indiana University Library and was extended and merged into the Sakai 2.1 release by the MIT OKI project.
To add a repository to TwinPeaks, one must write or obtain an OKI DR OSID implementation for that particular repository and then install the OSID implementation in their Sakai instance. Documentation for installing and registering a new OSID implementation within Sakai is available in the Sakai Development Resources area on collab.sakiaproject.org.
TwinPeaks can be enabled by changing the following sakai.properties setting to true.
# enable the twinpeaks feature in the WYSIWYG editor in legacy tools: true or false wysiwyg.twinpeaks=false
The TwinPeaks implementation in the Sakai 2.1 release should not be turned on in production systems without additional work. The Sakai 2.1 out-of-the-box only has a very simple repository configured and TwinPeaks only works with some of the tools (Announcements and the other legacy tools).
TwinPeaks is suitable for use on development servers and can be used to enable sites to begin the development of their DR OSID implementations. As we move towards 2.2, the integration of TwinPeaks into the resource tool and WSYWIG editor will be improved.
If you have any questions regarding TwinPeaks, please contact Jeff Kahn (jeffkahn@MIT.EDU).