Index: openacs-4/packages/dotlrndoc/www/doc/permission-portals.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/permission-portals.adp,v diff -u -r1.1 -r1.2 --- openacs-4/packages/dotlrndoc/www/doc/permission-portals.adp 23 Oct 2001 01:27:16 -0000 1.1 +++ openacs-4/packages/dotlrndoc/www/doc/permission-portals.adp 23 Oct 2001 16:58:38 -0000 1.2 @@ -1,5 +1,5 @@ -<%= [dotlrn_header "dotLRN Permissions - Portals"] %> -

dotLRN Permissions Portals

+<%= [dotlrn_header "dotLRN Portal Permissions"] %> +

dotLRN Portal Permissions

by Arjun Sanyal and Ben Adida, part of dotLRN Documentation.

@@ -18,226 +18,80 @@ the portal-based parts of dotLRN, for more documentation on the general permission scheme of dotLRN, see dotLRN Roles, Sections, and Permissions -

Administering Portals

+

Some General Portal Ideas

-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. -

+Students will have the ability to alter their personal portal, but up +to the point specified by a class administrator. In the example given +above, a class administrator could "lock" the "Class Announcements" +element in student's personal portals so they would not have the power +to remove it or alter its position. In this case, the administrator +would have contol over more than one portal, i.e. her +own personal portal and a "default" portal that is "cloned", including +the "lock", to create each student's portal when she registers for the +class. -

Unregistered Visitor

-An unregistered visitor is simply a user who browses the dotLRN -application without login information. +

-

Registered Visitor

-A registered visitor is one who has entered first name, last name, -email address and password information, and how has logged in using -those credentials. +Non-administrative users cannot grant any permission to anyone. Thus, +an "Student X lets student Y read her portal" scenarios are avoided. -

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). +

Administrative Permissions

-

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. +The administrative permissions CREATE and DELETE are only given to +those users whose roles are such that they would need to create and +destroy portals for scenarios such as the one given above. -

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

+

CREATE

- -

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

+

DELETE

+

Portal-level Permissons for Non-Admin Users

-

Per-Class Admin Page

+These permissions are at the level of individual portals for users +such as students. -Each class will have an administrative section in the dotLRN -application which will enable users to: +

READ

-

-

Permissions

+

EDIT

-

Per-Class-Instance Main Page

+

Portal-level Permissons for Admin Users

-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. +Admin users with the CREATE permission will be granted the following +permisson on the newly created portal. -

-

Permissions

+

ADMIN

-

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

- - <%= [dotlrn_footer] %>