(version 1.5 - info provided by Michael Beasley and Nadine Blackwood)
A worksite is created by users who have the site.add permission. This is determined by the user's account type. The account type determines the realm associated with the user's account. The !user.template.<type> realm is given to users with an account type of <type>. If the user does not have an account type (the type field is blank), or their is no !user.template.<type>, then the user gets the !user.template realm. If the site.add permission is checked for the .auth role in the user's realm, that user can create worksites. The account type can be seen/changed by editing the account with the Admin's User tool.
The creator of a worksite is automatically a member of the worksite and has a "maintain" role for the worksite. The role which the worksite creator gets is configurable. It can be changed by editing the !site.template.<type>, where type is the worksite type (viewable in the Admin's Site tool, and set to 'course' or 'project' when creating a site with Worksite Setup).
Users are added to a worksite by the site creator using Worksite Setup, and users may join a worksite if the worksite has been made joinable. The permissions that the user has in the worksite are determined by their role. The assigned role is specified by the person adding the user to the site or is automatically assigned based on information provided when the worksite was created if the user joins a worksite. The information contained in this document details permissions available for roles and their affect on how tools are used in a worksite.
Within a User-Created Worksite
The creator of a worksite has the ability to control what users can do with tools in their worksite. This is accomplished by specifying a role which will be used when a user is added or self joins a worksite. The role can be one of two default roles ("maintain" and "access"), or it can be a role that is created by the admin. The functionality to create a new role in the site is in the Admin Realm tool, and so is not available to normal users at this time.
When a role is created, options for each of the tools in the worksite have to be selected. Below are the permissions which are possible for each tool, along with summary notes regarding each. The default maintain and access roles have certain permissions enabled. In general, the maintain role has full permission to create, edit, delete in a worksite. The access role has fewer permissions, and cannot create content or delete in all tools. For example, by default the access role cannot upload files into resources, but can create chat messages and discussion replies.
The permissions enabled for each of these roles can be different for different types of sites. The defaults are set in the worksite's default template (e.g., !site.template.course or !site.template.project). Once the site has been created, its own realm can be edited to change the permission matrix for a given role. And, those users with a role that has worksite edit capabilities (the site.upd permission in the worksite's realm) can change permissions for a role for a particular tool. Permissions are edited in a tool via the tool's Permissions... page, accessible using the Permissions... item the Tool's toolbar.
Read: Allows users to view the schedule and to read schedule items. Without this permission, no schedule items appear when viewing the schedule tool, and the create new schedule item functionality is removed.
New: Should allow users to create new schedule items. However, all that is necessary is the Revise & Read permissions in order to create new schedule items. Currently, this permission is unnecessary. (See SAK-144 for bug report)
Delete: Should allow users to delete schedule items. However, all that is necessary to delete schedule items is the Revise & Read permissions. Currently, this permission is unnecessary. (See SAK-144 for bug report)
Import: Allows users to merge schedule tools from other sites (presumably, ones to which the owner has permission to edit). Requires the Revise & Read permissions.
Revise: Allows users to edit schedule items. This is the keystone permission; without it, the New, Delete, Import, and Revise permissions do not work.
New: Allows users to create new announcements
Read: Allows users to read announcements. Announcements tool give a "no announcement at this location" message when this permission is not set and all other options disappear without this permission.
Revise.any: Allows users to revise announcements created by anyone, even one's own.
Revise.own: Allows user to revise only the announcements created by the user.
Delete.any: Allows users to delete announcements created by anyone, even one's own.
Delete.own: Allows user to delete only the announcements created by the user.
Read.drafts: Allows users to read any draft announcements that are currently in this tool. If this permission is not set, the user can only view draft announcements that were created by the user.
Read: Allows users to access resources. Resource tool displays a "no resource item at this location" message when this permission is not set. No options are available without this permission.
New: Allows users to create new resources.
Revise: Allows users to revise or replace resources created by anyone.
Delete: Allows users to delete resources created by anyone. Requires the Revise permission.
New: Allows user to post new discussion items. Works in conjunction with New.topic for creating a new category, but New.topic is not needed for a user to create new replies.
Read: Allows users to read discussion items.
Revise.any: DOES NOT SEEM TO HAVE ANY RELEVANCE HERE. Unable to verify functionality. Allows user to revise any discussion item. This permission may not work properly. It is believed that this is not hooked up as there isn't a way to revise a disc.
Revise.own: DOES NOT SEEM TO HAVE ANY RELEVANCE HERE. Unable to verify functionality. Allows user to revise one's own discussion items. This permission may not work properly. It is believed that this is not hooked up as there isn't a way to revise a disc
Delete.any: Allows user to delete discussion items and discussion topics created by anyone.
Delete.own: Allows user to delete one's own discussion items.
Read.drafts: Allows users to read any draft posts currently in the tool, not just ones created by the user. Without this permission, user is only able to view user's own drafts. Requires the Read permission.
New.topic: Allows users to create new topics and categories. Requires the New permission.
Read: Allows users to view assignments
New: Allows users to create new assignments.
Revise: Allows users to revise assignments.
Delete: Allows users to delete assignments. Requires Revise permission.
Submit: Allows users to submit assignments. Instructors and assistants have to switch to student view (and this is hardwired in).
Grade: Allows users to grade assignments, if they would not normally be able to (instructors and assistants are able to grade automatically and do not have this set). I believe if you can create new assignments, you can also grade.
Drop Box Own: Has no effect at the worksite level.
New: Allows users to post new chat messages
Read: Allows users to read chat messages.
Revise.any: Works in conjunction with Delete.any and Delete.own. No revision of message functionality available.
Revise.own: Works in conjunction with Delete.own. No revision of message functionality available.
Delete.any: Allows users to delete any message. Requires either Revise.own or Revise.any to become functional. The trash can (for deletion) appears only when this permission is set.
Delete.own: Trash can is not visible if the Delete.any permission is not set. Unable to test functionality. Allows users to delete their own messages. It is believed that the delete.own functionality was not implemented.
New: Tells users what email addresses can be used to send and receive email on the worksite. Email sent from a valid email application will be stored (archived) and forwarded on the system.
Read: Allows users to read messages in the email archive.
Revise.any: Allows users to edit any message in the email archive. This permission is necessary when revising the tool information in a worksite that includes the Email Archive tool. Never hooked up as there is no UI for editing an email. Note: revise.any is required in order to edit the email alias field in email archive Options. This is a bug that has been reported in Jira.
Revise.own: Allows users to edit their own messages in the email archive. This permission is necessary when revising the tool information in a worksite that includes the Email Archive tool. This permission does not work. Never hooked up as there is no UI for editing an email.
Delete.any: Allows users to delete any message in the email archive.
Delete.own: Allows users to delete their own messages in the email archive. This permission does not work. It is believed that only delete.any has been implemented.
Add: Has no effect at the worksite level.
Delete: Has no effect at the worksite level.
Update: Allows users to edit worksite information, add/delete site tools, view members of the site, add participants to the site, and duplicate the site.
viewRoster: Allows user to see the list of participant, even without the Update permission.
Visit: Allows user to access a worksite. If this permission is not checked, the user gets a "Site Unavailable" message.
Visit.unp: Has no effect at the worksite level.
There are no permissions available for this tool.
