Admin Tools Test Case Information

This page is meant as a means to collect together resources to aid testing of admin-only tools such as Realms, Sites, Users, and so on.

Realms

The test case documentation for the Realms tool relies upon knowledge of how permissions work in Sakai. This file contains a table with the permissions associated with every role used in the Realms TC.

For a more in-depth guide to Realms, please visit the Sakaipedia here: Worksite Permissions.

Explanation of Realms tool

Typically, user support staff make use of the Realms tool to enter provider ID's¿in other words, to point a specific site in CTools to the roster for a course in UMIAC. In turn, the students on the roster will be entered into the site's participant list without any further intervention. As students drop or add the class, these changes will be reflected in the site's participant list.

However, the true power of the Realms tool lies in the ability to create and edit roles in a specific site, create and edit roles for a specific type of site or even all sites, and to edit the permissions of specific user types (or create new user types).

Before explaining how these tasks are accomplished, here is some background: The essential component of user roles and the Realms tool is the permission. Theoretically, there is a permission that corresponds to every possible action in CTools, and whether or not the user has that permission determines whether or not he or she can perform the action. When all of the permissions are collected together, they constitute a role. Each user has a role in a given site¿a set of permissions. This role can change from site to site, meaning, for example, that there is nothing intrinsically "instructor-ly" about a user that is an instructor on a course site.

In the Realms tool, one can look up any site (including My Workspaces) and see the roles on that site (and edit, delete, or add roles). In addition, there are special entries marked with an "!" so that they will sort to the beginning of the list. These entries are special in that they determine what roles will appear on a site when it is created and what permissions a user will have based on his or her type. These two basic types of entries are !site.template and !user.template, respectively.

The !site.template determines what roles will appear on a generic site. In turn, the !site.template.course entry determines the roles that appear on a course site, the !site.template.project determines what appears on a project site, !site.template.myworkspace determines what appears on a My Workspace, and so on (at the University of Michigan, for example, there are templates for different kinds of GradTools sites and for legacy CourseTools: Next Generation sites).

Why is there a generic template and specific templates? In normal user of CTools, only the specific templates really matter. However, users with admin access can use the Sites tool to create new sites and have the opportunity to type in the type of site (or leave this field blank). If CTools does not recognize the type of site that the admin enters, then it uses the generic template... and if the admin has also gone into Realms and created a new specific template, the Sites tool lets the admin link a site to the new template.

The user templates work in a similar way; there is a generic user template (!user.template) and templates for uniqnames (!user.template.uniqname) and for friend accounts (!user.template.friend; these are UM-specific creations; Sakai instead uses "registered" and "guest" and these templates exist in CTools). Again, in typical use of the system, only the specific templates matter. However, the Users tool lets an admin create a new user and type in what kind of user it is. If the system doesn't recognize the type the admin has entered, then it uses the generic user template. This capability lets an admin create a new user type or, for example, give a friend account the same privileges as an uniqname account.

The user templates all include two roles¿one for anonymous users and one for authenticated users. There are also two special entries: !site.user and !pubview. !site.user determines roles for a My Workspace but seems to have been superceded by !site.template.myworkspace. !pubview determines permissions for unauthenticated users that attempt to view publicly viewable resources (presumably, after finding them in the Sites tool in the Gateway).

If we were to redesign the Realms tool, I would assume that the basic functions:

Add a user type/edit a user type
- Uniqname
- Friend
- Generic
Add/edit roles on a specific site
Add/edit roles for a type of site
- Project
- Course
- GradTools
- Admin

The last item in that list is significant¿at UM, support staff are granted admin access by being added to a special site with a role that grants users permission to do admin functions. This is the only case that I know of where a role is universal¿users with admin access are always admins, no matter what site they are on. However, I do not know what model Sakai/CTools will user for granted admin access to support staff in the future, and this may not be something to really worry about.

Site Archive

The Site Archive tool is meant for exporting a site in Sakai to XML. This XML could then be imported into another site on the same system, taken to another Sakai system and imported, or feasibly reconstituted outside of Sakai as a sort of snapshot/archive of the site.

Until a 2004, the Site Archive tool was the only means of transferring content from one site to another. As a result, it does not perfectly transfer content; it changes items into drafts where possible, and removes student data (such as assignment submissions). Because there are now ways for end users to transfer their content, it is not necessary for admins to intervene whenever a user wants their content transferred.

Currently, the contents of Email Archive are transferred at the request of a Sakai institution.

The XML from exports appears in a directory somewhere on the server; I believe the destination is set by a config file somewhere. For imports, the XML to be imported must exist in that same directory.

When the University of Michigan migrated from its older course management system, it added the Batch Import feature. There is no Batch Export because that was handled outside of Sakai.

Use this file when testing Site Archive using the test case matrices.