Index: openacs-4/packages/dotlrndoc/www/doc/index.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/index.adp,v diff -u -r1.1 -r1.2 --- openacs-4/packages/dotlrndoc/www/doc/index.adp 14 Oct 2001 21:42:58 -0000 1.1 +++ openacs-4/packages/dotlrndoc/www/doc/index.adp 23 Oct 2001 16:58:51 -0000 1.2 @@ -9,6 +9,7 @@

  • Nomenclature
  • Roles, Sections, and Permissions +
  • Portal Permissions
  • Architecture Overview 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] %>