dotLRN Roles, Sections, and Permissions

dotLRN Roles, Sections, and Permissions

by Ben Adida, part of dotLRN Documentation.

dotLRN includes significant components of functionality and an architecture for integrating these components. Around these components, there must be a coherent and consistent model for roles and permissions throughout the system. This document defines the necessary roles, application sections, and rules for access in the dotLRN application.

Roles

Roles in the dotLRN system are considered from a logical standpoint. It is perfectly conceivable that an actual user take on more than one role. It is also conceivable that a logical role is represented by multiple physical underlying roles and permissions.

Unregistered Visitor

An unregistered visitor is simply a user who browses the dotLRN application without login information. An installation of dotLRN may disallow unregistered visitors, if it so chooses.

Registered dotLRN Guest

A registered dotLRN guest is a registered user (first name, last name, email, password are entered) who has logged in and is using those credentials. This user is enabled only for a particular class or club, and does not have access to the generic dotLRN workspace.

Registered dotLRN User

A registered dotLRN user is a registered user how has logged in using those credentials. A dotLRN user can browse all available public classes and clubs.

Registered Student of an Instance of a Class

A registered student of a class is one who has requested association with a particular instance of a class (e.g. Micro-Economics, Spring 2002 Section A), and who has been approved (usually by a professor, a TA, or an administrator).

TA of a Class Instance

A TA of an instance of a class is a registered user who serves as a Teaching Assistant for the class, having some administrative responsibilities. TAs are usually designated by professors or administrators of a class's instance.

Administrator of a Class Instance

An administrator of an instance of a class is a registered user who serves to perform organizational/administrative duties for the class, including registration, schedule and venue arrangements, etc...

Instructor of a Class Instance

An instructor of an instance of a class is a registered user who teaches the actual class instance in question. Instructors are often professors, but may not be (thus the use of the more functional term "Instructor" rather than the status term "Professor").

Member of a Graduating Year

A member of a graduating year is a registered user who is a student of a particular graduating year. This grouping may be needed for mass mailings, alumni clubs, etc...

Member of a Community

A member of a community is a registered user who has signed up (and been approved) to be part of one of the dotLRN communities. A community functions much like a class instance, but without the association to the teaching of a particular subject.

Administrator of a Community

An administrator of a community is a registered user assigned to coordinate a particular community.

Sections of the Application

The dotLRN Application is composed of a number of sections which serve various roles. These sections can be described with a varying level of granularity. The following description matches the necessary level of granularity for matching permissions and roles.

Main Public Site

Every dotLRN site will have a completely public section that describes the general purpose of the application. This will be mostly information material, with very little interactivity of any kind.

Permissions

Per-Class Main Page

Each class (e.g. Micro-Economics) will have a section in the dotLRN application. This section will describe the goals of the class, general information about it, and will remain unrelated to any specific instance of the class.

A registered student of an instance of that class will be presented with links to the proper instance-specific sections.

Permissions

Per-Class Admin Page

Each class will have an administrative section in the dotLRN application which will enable users to:

Permissions

Per-Class-Instance Main Page

Each class instance (e.g. Micro-Economics, Spring 2002 Section A) will have a section in the dotLRN application. This section will look very different depending on the state of the visitor.

For a registered student, TA, or Instructor of the class instance, the section will present all available options for the particular instance, including discussion forums, file storage, FAQ, surveys,etc...

For a user not registered with this class instance, the section will present general information about the class instance, possibly some public files (like a syllabus), and the ability to request registration for the class.

Permissions

Per-Class-Instance Admin Page

Each class instance will have an administrative section which will allow for:

Permissions

Per-Class-Instance-Package Main Page

Each package within a class instance defines a section of the dotLRN application (e.g. bboards for Micro-Economics, Spring 2002 Section A). The functionality for these sections will be specific to the subpackages involved.

Permissions

Per-Class-Instance-Package Admin Page

By the same token, each package within a class instance defines a section of the dotLRN application for administration. The functionality is subpackage-specific.

Permissions

Per-Community Main Page

dotLRN will also support communities, each of which will have its own section, much like a class instance. This section will lead to all subpackages supported by this community. Users who are members of the community will access all functionality, while other users will only see basic community information.

Permissions

Per-Community Admin Page

By the same token, each community will have an admin section that allows community administrators to manage community membership, general information and subpackages.

Permissions

Per-User Main Page

Each user will have a main page that centralizes access to all of that user's class instances, communities, and all the data within these sections. This is a personal view on every piece of user-relevant data.

Permissions