Introduction
Any new software can be intimidating to a new user. When implementing new software, there are many important setup decisions that must be made. Right or wrong, these decisions are lived with for quite a while. Role definition in Sakai is a strategic setup up activity. Roles determine what the role-holder can do when in the worksite. For example, the Instructor role has authoring capability, grading capability, etc. It would not be appropriate for students to have these capabilities. This article can aid the institution new to Sakai, as well as the experienced Sakai institution that needs to reassess their role implementation.
There is tremendous technical documentation available on Sakai Permissions. If you are new to Sakai, you may find the Sakai Permissions document intimidating, and maybe a bit confusing. This article is intended to be a notch or two above the detail in Sakai Permissions. After reading (and understanding) this article, take a look at Sakai Permissions. This article will help you understand and come up with a strategy for defining your roles. Sakai Permissions will take you down into the detail and show you how to implement your new roles within Sakai.
Understanding Sakai Concepts
To better understand roles and permissions, it is important to introduce a few Sakai concepts. Understanding these basic Sakai concepts will aid with knowledge acquisition and integration, especially for the newer Sakai user:
Worksites
There are two types of worksites, by default: course and project. The course worksite is what you would expect for a traditional classroom, such as Math, English, etc. A project worksite is an on-going collaboration area such as the Art Club, Academic Counselor, etc. More technically, a worksite has a worksite identifier; and organizes resources. These resources include tools, files, links, and other content. Additionally, a worksite has a unique definition of it's own access permissions.
Tools
Tools provide features and functions that aid in creating a web site that facilitates teaching, learning, and collaboration. Examples of Sakai tools are: Announcement tool, Syllabus tool, Calendar tool, Resources took, Tests and Quizzes tool, and Gradebook tool.
Permissions
A permission is an attribute that defines specific actions. For example, in the Announcement tool the "read" permission - is the ability to read within this tool; the "new" permission - is the ability to create announcements; the "delete.any" permission - the ability to delete any announcement; the "revise.any" permission - is the ability to modify any announcement; the "revise.own" permission - is the ability to modify only your own announcements that you created. In summary, permissions define and permit specific user access for a worksite.
User Role
A user role is nothing more than a grouping of permissions. For example, Sakai out of the box (OOTB), has an Instructor role, Student role, and Teaching Assistant role for course worksites (and Maintain and Access roles for project worksites.) One would expect the Instructor role to have the most rights and privileges, such as authoring; the student to have limited authoring but maximum reading and submitting; and the Teaching Assistant to have some authoring but under the control of the Instructor.
User Type
The user type is assigned at the time of user creation. If a user type of "Registered" is given, then the user has the ability to create worksites. If the user type is "Guest" or if the user type is left blank, then the user does not have the ability to create worksites. User types and user roles are oft confused.
Realms
Permissions granted to a Sakai worksite are specified in the worksite's realm. A realm contains role definitions and for each role, the permissions which that role has for each tool.
Here is a diagram to help in the understanding of roles and types. Note that a user type is static, while a user can have different roles in different worksites concurrently.
Admin types and roles in Sakai
Sakai OOTB
What do Sakai Roles look like OOTB?
For Course Worksites The Roles Are:
Instructor - Has permissions you would expect:
- Site create/delete
- Content authoring
- Adding/creating content
Teaching Assistant
- Has fewer permissions than the Instructor, but more than the student
Student
- Read
- Submit
- Limited create (for example create an entry/response in a forum posting or chat)
For Project Worksites The Roles Are:
- Maintain (similar to the Instructor role)
- Access (similar to the Student role)
You may have heard about two other roles: anon and auth. Let's not worry too much about these at this time. They are explained in Sakai Permissions, and are more germane to that content and level of detail.
Strategy
As you go through this process, you may discover there are exceptions with the permissions that you would like to define for the various roles. You should try to identify the more general needs and create the role based on the broader need. Many of the tools have a permissions option for the Instructor role to modify. These tools are: Announcements, Assignments, Chat Room, Discussion, E-mail Archive, Resources, Schedule, and Wiki. Exceptions can be handled directly by the instructor modifying permissions in these tools (did you just hear training opportunity?) For the other tools, if the instructor needs to have the permissions tweaked, they would have to get in touch with the Sakai Administrator, or just do with the default permissions (did you just hear the importance of identifying the general need?)
The University of Michigan (UMICH) has been instrumental with Sakai as a founding member. In particular, they have shared their role definitions and implementation. This can be found in Appendix B of the Sakai Permissions. The first step in your Role Definition Strategy is to get the Sakai Permissions document and get Appendix B.
The UMICH Roles Are:
- Owner
- Instructor
- Affiliate
- Assistant
- Student
- Observer
Let's not get hung up on the names. A part of this strategy is to determine what the names of the roles are that make sense to you and your institution. The second step it to get a test or sand-box version of Sakai and have the Sakai Administrator (SakAdmin) present, so you can ask the SakAdmin to change permissions on-the-fly.
The number of roles your institution ends up with is not important. It does not matter if there are more or less than UMICH. What is important is your understanding of your institutions organization, structure, and at what level decisions are made; and, if these structures and decision-making levels are the same for each department that are going to be using Sakai. We are not privy to UMICH's requirements when they created these roles. So let's not focus on if their implementation is right or wrong, because it fits their needs and is therefore perfect for them. Instead, let's try to understand the components of the roles and use that as stimulation to determine what roles make sense for your institution.
UMICH Roles Functionally:
Owner
This is the most powerful role. It is the same as the Instructor role, except the Owner has site delete and the Instructor role does not.
Instructor
This is a powerful role and has everything that is needed to maintain a worksite, except the ability to delete a worksite.
Affiliate and Assistant
These are close to the Instructor role, but typically can not delete items the instructor created. The Affiliate role seems to have more ability to closely manage the discussion groups versus the Assistant.
Student
This has the typical student permissions as defined earlier.
Observer
This has read-only permissions.
Let's explore each of the UMICH roles using what works for them as the analysis starting point, to help determine what works for your institution. This is the process we will follow:
- Identify person/people in name, title, or both that will be given this role
- Determine the name for the role
- Determine the permissions for the role
Owner Role
Let's start with the Owner role. First off, that is a great name for this role since it is a powerful role. But perhaps your institution has a different name requirement: possessor?, proprietor?, controller? The owner of a site (that is the person that could delete a site) at your institution would be whom? The Dean? Instructional Designers? The Director of the Center of Education and Teaching and Learning? The person (or liaison) between your department and the registrar's office that is responsible for your department's Sakai site creation? There is no right or wrong answer. But select the person/people in name, title or both that would perform this function; and select the name for this Owner Role.
OK, that was probably the easier part. Now you need to review UMICH's Owner permissions. Do they work for you? Well some of these are intuitive and some are not. So now you need to ask your SakAdmin to add/remove permissions, one at a time, then log in with the Owner role and observer what that permission added/took away. Is that what you want/need? This may take a while for permissions/functions that are unclear to you or are on the bubble for wanting/deleting from the role. Here is a suggestion to facilitate this decision process. Chances are there are more than one person making these decisions. Get these people in a room. Have the SakAdmin upfront with Sakai projected on a screen. As you ask the SakAdmin to change permissions, have this done on the fly so the group can see what the results are and can make the decision quickly. This may be an all day meeting doing it this way, but if you do it remotely, it may take months or years to come to an agreement on roles and permissions!
Now that you have decided on the Owner role, don't cast these in concrete just yet. Be flexible, a definition of the other roles may trigger a need for a change in the Owner role.
Instructor Role
The first question here is do you want instructors to be able to delete worksites? If the answer is yes, then your Instructor and Owner roles are identical. If this is your requirement, great. However, it is a good practice not to give the Instructor role the ability to delete worksites. Ask yourself what is the use case where they need to delete a worksite? ... and not include their supervisor (or other person in authority) for permission?
Now let's perform the same exercise we just did with the Owner role. Is Instructor an appropriate role name for your institution? Should it be Faculty? Teacher? Coach? Facilitator? Trainer? Professor? Don't forget to consider the politics of your organization. Do you call them instructors and does another department call them faculty? Do you need to consider having more than one identical role? One called Instructor and another call Faculty? There is no right or wrong decision. Make the call that makes sense for your institution.
Again, that was probably the easier part. Now it is time to decide if the UMICH Instructor role permissions are appropriate for your institution. Compare them to Sakai Instructor roles OOTB. You will notice they are essentially identical. Therefore, you should be able to use the Instructor permission OOTB with confidence. However, go through the exercise of reviewing the permissions on paper with your SakAdmin close by to demonstrate specific permissions. This will help you gain confidence with Sakai, permissions, and role behavior.
Affiliate And Assistant Role
I think you understand the process by now. Do you have Graduate Assistants at your institution? Graders? Assistants? Affiliates? Undergraduate student assistants? Understand your institution's roles in this area and what each needs to do. Start with the Teaching Assistant role OOTB; compare this to UMICH's Affiliate and Assistant Roles. Go through the permissions demonstration exercise with your SakAdmin.
Implementation
An outcome of this exercise should be a spreadsheet (or word processing table) that contains the Role Names across the top, the permissions down the side, and tick marks at the intersecting boxes indicating what roles have what permissions. You are now armed with what you need to proceed. Get with your SakAdmin, read the current Sakai Permissions document, and follow the instructions to create roles in Sakai.
Congratulations! You are on your way to a successful Sakai implementation!
| Attachment | Size |
|---|---|
| Types Roles Admin v01.png | 195.03 KB |
Your Author:
