+
+
+dotLRN is built on OpenACS 4.x, a modular architecture for
+community-oriented web applications. dotLRN is also
+modular in that new course management functionality
+can be added as desired. Since dotLRN modules must function within the
+dotLRN architecture, dotLRN modularity must be built on top of OpenACS
+modularity.
+
+
+
+The dotLRN architecture attempts to define a framework within which
+learning communities develop. A learning community may take many
+different forms, but remains the crux of the architecture.
+
+
+
Learning Community
+
+A Learning Community is architected as a series of
+OpenACS components, with a heavy use of the subsite
+concept. One community is represented by:
+
+
+
a group: this will serve to define membership
+and roles within the learning community. These groups are not
+necessarily all in the same group type.
+
a site node: this will serve to define a
+consistent URL for the learning community, and to segment away each
+communities from one another. An example is /dotlrn/alumni-1998.
+
an instance of the dotLRN Community Manager
+package: this will serve to display community-specific data
+in a way that is clearly segmented away from the other learning
+communities using the acs-subsite constructs.
+
+
+
Class Instances & Clubs
+
+There are two different types of learning communities in the basic
+dotLRN release: class instances and
+communities (clubs). Both have the same functional
+capabilities but have different attributes and roles for their
+respective members.
+
+
Class Instances
+Class Instances are related to a particular class, and must specify:
+
+
Year (e.g. 2002)
+
Term (e.g. Spring)
+
Section (e.g. Section B)
+
Start Date
+
End Date
+
+
+The fist three parameters may be stored as separate items, all in one,
+or combined in some way. The current architectural direction is to
+separate Year and to group Term and Section, but this may change. In
+terms of the global architecture, this isn't very critical.
+
+
+
+Since all class instances have a common basic set of parameters, the
+class instance groups should all be a single core group type, called
+Class. The Class group type defines the
+attributes above (year, term, section).
+
+
+
+In addition, in order to group class instances by the class they refer
+to, the Class group type is subtyped into further group
+types, where one class is itself a group type. For example,
+6.001 is a group type, whose parent group type is
+Class. Then, 6.001 is the group type that all
+instances of 6.001 belong to. 6.001 - Spring 2002, Section B
+is a group of group type 6.001. This architecture allows for:
+
+
+
class-specific attributes in addition to the generic set,
+
relating different class instances to a single class,
+
reusing existing OpenACS 4 concepts of group memberships and permissions.
+
+
+
Communities (Clubs)
+
+Clubs are fairly generic Learning Communities, with no specific
+attributes. Clubs are timeless, in that they don't start and end on
+certain dates. Membership lists evolve, but the clubs remain unique,
+without instances.
+
+
+
+Thus, unlike class instances, the group type structure for clubs can
+be much simplified. A root group type, called Club can
+encompass all club groups without any additional level of group typing.
+
+
+
dotLRN Packages
+
+Learning communities have various packages of functionality. These
+packages are much like existing OpenACS 4 packages, but with added
+specifications, special callback interfaces, and predictable APIs that
+not every OpenACS 4 package will have.
+
+
+
+Thus, a dotLRN Package is composed of two OpenACS 4
+packages:
+
+
+
an OpenACS 4 raw functionality package (e.g. bboard), whose
+dependencies are completely independent of the core dotLRN application.
+
a simple OpenACS 4 package (e.g. bboard-dotlrn), dependent on the core dotLRN
+application, whose role is to wrap the raw OpenACS 4
+functionality in the required dotLRN APIs.
+
+
+dotLRN will present most of its interface in portal form. Each dotLRN
+package will present its information inside a portlet within
+the appropriate portal page.
+
+
+
+The current Portals package is inappropriate for this effort, given
+that there is no clean API for creating portal pages, setting up
+portal pages configuration, and rendering portal pages
+programmatically. Instead, dotLRN will need a much more programmatic
+portal mechanism.
+
+
A Portal Page
+
+The New Portals Package (NPP) will feature the
+ability to programmatically create and edit single Portal
+Pages. A single Portal Page will be defined by:
+
+
a layout type (3-columns, 2-columns, etc..)
+
a set of portlets and their individual configuration information
+
a set of permissions for viewing the portal page
+
+
+
+
+The dotLRN application will then create, configure, and associate
+individual portal pages with specific users' sections of the
+site. This will allow portal functionality to exist within the dotLRN
+application without handing over all control to the portals package.
+
+
Portlets
+
+The NPP will require portlet packages much like the old portals
+package. Each portlet package is responsible for:
+
+
rendering itself within a portal page
+
providing a set of editable parameters
+
linking to all appropriate features in the underlying OpenACS
+package
+
+
+
The Per-User Interface
+
+Each user will have a single NPP interface which groups information
+from all dotLRN classes in one page. Given the subsited architecture
+of each class, the per-user interface must be subsite aware, and must
+be able to query information across subsites.
+
+
+
+This document details the precise steps in moving forward with dotLRN development.
+
+
+
+
Portals Enhancements
+
+
Make all explicitly-sourced Tcl scripts into procs. Fix templates.
+
fix the path to template finding for each portal element (no symlink!)
+
fix the parameter setting (specifically in bboard)
+
user-editable placement of portlets. Allow any portal page to jump into "editing" of the portal page (if the user has permission to do so).
+
remove all user_id information from a portal page. We want to regulate access using the permissions module, and there is no need to map to a user inside the portals package.
+
add permissions checking to each portal page displaying.
+
+
+
+
+
allow layout to be changed by user
+
add the ability to have a model layout that can be copied. For example, a class admin will set up a portal the way it's supposed to look when someone signs into the class. This layout will be copied for a user. But then the user can change the portal.
+
However, some portal elements will be "unremovable", mandatory in some sense. The way this works is that each portal element in the "model" layout will carry permission models that will be copied over when a new portal page is created based on the model. Thus permissions must exist on a per-portal element level. Maybe for displaying, and at least for adding / removing.
+
This means that we need to rethink how data sources are made available to a portal. Maybe via permissioning. How does a user get to add a data-source to a portal or not?
+What Ben means: we have data sources in the overall system, say bboard, faq, and fs. However, to page #123, only bboard and faq are *available* as potential data sources. The dotlrn-bboard package will first make the bboard datasource AVAILABLE to the page in question, and then will actually add it. Thus, when removed, the datasource remains available to be re-added.
+
+More on removing portal elements: anyone with page-level permissions (which permission exactly is yet to be determined) can add available data sources to the given page. Each portal element that is added by the user will automatically gain the permission to be removed. However, some portal elements added programmatically might not be removable by the viewing user.
+
+
+
dotLRN Course Administration
+
+
+
Ability to add profs, tas, students, and admin roles to a particular class.
+
Set a community to be active or not. Change the data model to make this work.
+
+
+
+
dotLRN Permissioning
+
+
Define all permissions and how they are used in dotLRN.
+
+
access to portal pages and admin of portal pages
+
add/remove on portal elements
+
possibly access on portal elements
+
read/write/admin on community types (site-wide, and admins for a usual class)
+
read/write/admin on communities (profs/tas/admins)
+
carry the permissions down to the specific packages within each community (inherit)
+
+
abstract out permissions as much as possible within the API.
+
set up explicit non-permissioned APIs when absolutely necessary (but avoid it as much as possible).
+
+
+dotLRN is a Course Management System which means it
+helps manage courses, but does not perform the actual instruction of
+the courses. This document defines the nomenclature
+in the dotLRN project, because the components of a Course
+Management System are named very differently by various teaching
+institutions. In particular, since dotLRN is being developed for MIT
+Sloan, an attempt is made to cleanly work within existing MIT
+terminology while being generic enough to use by all.
+
+
+
+
Class
+
+A class is a topic being offered by the
+institution. An example is "Introduction to Micro-Economics". Some
+institutions use the term "course", but this conflicts with MIT's
+reference to entire departments (Course 15). A class is thus a single
+topic that spans across years and does not specify a single offering
+of that topic.
+
+
Class Instance
+
+A class instance is a particular offering of a
+class. An example is "Introduction to Micro-Economics - Spring 2002,
+Section A". A class instance thus has a very well-defined student
+list, professor, and TAs. It has specific material relevant to that
+offering of the class, a schedule, news events, etc...
+
+
Student
+
+A student is an individual who is registered for a particular class
+instance.
+
+
+
Instructor
+
+An instructor is one who teaches a particular class instance. An
+instructor could be a professor in title or not. The term instructor
+allows the system to be more flexible to different teaching
+environments.
+
+
TA
+
+A TA (Teaching Assistant) is one who assists the instructor in the
+teaching of the class instance.
+
+
Administrator
+
+An administrator is one who assist in managing issues surrounding a
+class instance, but doesn't play a role in the teaching process.
+
+
+
+<%= [dotlrn_footer] %>
Index: openacs-4/packages/dotlrndoc/www/doc/permission-overview.adp
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/permission-overview.adp,v
diff -u -N
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ openacs-4/packages/dotlrndoc/www/doc/permission-overview.adp 14 Oct 2001 21:42:58 -0000 1.1
@@ -0,0 +1,235 @@
+<%= [dotlrn_header "dotLRN Roles, Sections, and Permissions"] %>
+
+
+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.
+
+
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.
+
+
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
+
+
All users can access this section
+
+
+
+
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
+
+
All users can access this section
+
Registered users associated with a class instance of this class
+will see specific links to the proper class instances
+
+
+
+
Per-Class Admin Page
+
+Each class will have an administrative section in the dotLRN
+application which will enable users to:
+
+
create new instances of the class
+
assign instructors, TAs, and administrators to existing instances
+of classes
+
edit standard class information (description blurb, etc...)
+
+
+
+
Permissions
+
+
Only dotLRN system administrators can access this section
+
+
+
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
+
+
All registered users can access this section
+
Only registered users associated with this class instance can
+access the full functionality
+
+
+
Per-Class-Instance Admin Page
+
+Each class instance will have an administrative section which will
+allow for:
+
access to various subpackage administration (bboard, FAQ, news, etc..)
+
general information updates (class instance blurbs)
+
+
+
+
Permissions
+
+
Only class instance administrators, TAs, and instructors can
+access this section
+
+
+
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
+
+
Only registered users associated with this class instance can
+access this section
+
+
+
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
+
+
Only instructors, TAs, and administrators of the class instance
+in question can access this section
+
+
+
+
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
+
+
All registered users can access this section
+
Only members of the community at hand can access
+community-specific chunks/links
+
+
+
+
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
+
+
Only community administrators can access this section
+
+
+
+
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
+
+
Only the user in question can access her main page.
+
+
+<%= [dotlrn_footer] %>
Index: openacs-4/packages/dotlrndoc/www/doc/permission-overview.txt
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/Attic/permission-overview.txt,v
diff -u -N
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ openacs-4/packages/dotlrndoc/www/doc/permission-overview.txt 14 Oct 2001 21:42:58 -0000 1.1
@@ -0,0 +1,81 @@
+
+dotLRN Permissioning
+====================
+
+This document describes the issues surrounding general permissioning
+in dotLRN. It defines the roles and access rules for the entire
+system.
+
+Roles
+-----
+
+- Unregistered Visitor
+- Registered Visitor
+- Registered Student of a Class
+- TA of a class
+- Administrator of a class
+- Instructor of a class
+- Member of a graduating year
+
+- Member of a community
+- Administrator of a community
+
+
+Sections of the Site
+--------------------
+
+- Main Site
+
+All users can view the page
+
+- Per-Class Main Page
+
+All users can see the description of the class in general. Users who
+are registered for a particular instance of that class see links to
+those term offerings.
+
+- Per-Class Admin Page
+
+The sitewide admins can access this section which allows:
+ - creation of new instances of this class
+ - assignment of profs and tas to each instance of a class
+ - editing the main blurb about each class
+
+- Per-Class-Instance Main Page
+
+Users not registered for this instance of this class see only an
+informational page about the class, including the public files like
+the syllabus.
+
+Users registered for this instance of this class see their full portal data.
+
+- Per-Class-Instance Admin Page
+
+Profs, TAs, and admins for this class instance can see the admin section
+for a class. This admin section allows management of class membership.
+
+- Per-Class-Instance-Package Main Page
+
+Users registered for this instance of this class can see this page,
+and that's it. No one else can access this.
+
+- Per-Class-Instance-Package Admin Page
+
+Class-Instance TAs and profs can access this.
+
+- Per-Community Main Page
+
+Community Members will see the full membership page, much like a class
+page. Non community members will just see a general community
+description page.
+
+- Per-Community Admin Page
+
+Community Admins will be able to determine community membership.
+
+- Per-User Main Page
+
+Each user will have access to her main page, which will link all basic
+packages.
+
+
Index: openacs-4/packages/dotlrndoc/www/doc/schedule.adp
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/Attic/schedule.adp,v
diff -u -N
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ openacs-4/packages/dotlrndoc/www/doc/schedule.adp 14 Oct 2001 21:42:58 -0000 1.1
@@ -0,0 +1,90 @@
+<%= [dotlrn_header "dotLRN Schedule"] %>
+
Chunks of functionality in working order on Oracle (pure functionality, not interface):
+
+
+
bboard
+
faq
+
file-storage
+
news
+
calendar
+
+
+
Working code on Oracle/PG for:
+
+
loading
+
class creation
+
major administration tasks
+
+
+
+
+
September 14th, 2001
+
+
Further tuning to architecture
+
Half-functional surveys
+
Programmatic Design of New Portals Package (NPP)
+
+
+
September 21st, 2001
+
+
Cleaned-up chunks of functionality in Oracle (and hopefully PG):
+
+
bboard
+
faq
+
file-storage
+
news
+
calendar
+
+
+
Design of 2 Additional Modules
+
Half-functional NPP
+
Working code on Oracle/PG for complete class/club management
+
+
+
September 28th, 2001
+
+
Fully-functional NPP on Oracle and PG
+
bboard and faq NewPortlets functional
+
Fully-functional surveys
+
Half-functional per-user page
+
+
+
October 5th, 2001
+
+
surveys, calendar NewPortlets functional
+
fully-functional per-user page
+
+
DEMO of functional SloanSpace 2.0 / dotLRN 1.0
+
Preliminary implementation of 2 Additional Modules
+
+
+
+
October 12th, 2001
+
+
Triage of major changes to dotLRN 1.0
+
+
+
October 19th, 2001
+
+
Mostly-functional implementation of 2 Additional Modules
+
+
+
October 26th, 2001
+
+
November 2nd, 2001
+
+
November 9th, 2001
+
+
November 16th, 2001
+
+
+
+
+<%= [dotlrn_footer] %>
Index: openacs-4/packages/dotlrndoc/www/doc/subsite-use.txt
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/Attic/subsite-use.txt,v
diff -u -N
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ openacs-4/packages/dotlrndoc/www/doc/subsite-use.txt 14 Oct 2001 21:42:58 -0000 1.1
@@ -0,0 +1,117 @@
+
+Subsite Quicky
+==============
+
+- Group Type: Company
+- Group: OpenForce
+- Relationship Type: Employment
+- Member: Ben Adida
+- Relationship: Ben Adida is employed by OpenForce
+- Relationship Segment: Employees of OpenForce (cross of one Group and one relationship).
+- Site Node: /6.001/bboard is a node of the site
+
+
+
+Ideas for Using Subsite for dotLRN classes
+==========================================
+
+- Group Type: class
+- Group Type: c6001, parent type class.
+- Group Type Arguments for class: Year, enumeration; Semester, enumeration.
+- Group: 6.001 Fall 2002
+- Various packages:
+ /dotlrn/6.001/fall-2002/bboard
+ /dotlrn/6.001/fall-2001/file-storage
+- Relationship Types: Student, TA, Professor (possibly others)
+- are relationship types configurable at web level? good question...
+- Relationship Segments: students of a class. TAs of a class. Profs of a class.
+
+- each class has a node, and the packages associated with it are subnodes within it
+
+- the question is permissions: do we permission /6.001/bboard to those
+ who are part of 6.001, or do we permission specific bboards? There
+ are two issues here:
+ 1. when going to /6.001/bboard, we want only the 6.001 bboards to be
+ displayed. How we scope this is not yet clear. OKAY! Now it is. If
+ you say "new application" then it effectively creates a new
+ scope. So there is an easy way to scope this! Excellent baby. Very
+ very good.
+ 2. when going to /6.001/bboard, we want permissions to be applied
+ correctly with respect to those bboards. That means permissions
+ should be SCOPED to the specific bboards, but the bboard package
+ must be scope-aware to only display the appropriate data.
+
+ 3. NEW DATA: Okay, permissions map to each instance of a package. So
+ we can actually set permissions on the instance of the package,
+ and then we're all set. This is very good.
+
+- the issue is how to put together a homepage that encompasses the
+ various data from all classes for a particular student. We might
+ have to write some serious custom code there.
+
+- calendaring information, specifically, where we want to mix in one
+ view all the events for one student.
+
+- when creating a class, we'll create a group, we'll mount the right
+ packages. We'll have to figure out how to create hooks so that
+ creating a bboard in /6.001/bboard will automatically scope and
+ permission things correctly
+
+- we'll create a class manager package that is the basic application
+ that is mounted at /6.001/. This will have to be scope-aware, to
+ display the right name and such. This will allow unsubscribed
+ students to sign up, and subscribed students to immediately see the
+ right info. This package may simply be an extension of the portals
+ package. A modified portals package, or a package that relies on
+ portals.
+
+
+WHAT HAPPENS BEFORE ANY CLASS IS ADDED
+======================================
+
+- All packages that will be needed must be loaded and installed
+- All data model and Tcl files initialized correctly
+- We don't ever want to restart the server afterwards!!
+
+- Group Type "Class" is created with appropriate attributes
+ - Semester
+ - Year
+
+
+
+WHAT HAPPENS WHEN A NEW CLASS IS CREATED
+========================================
+
+- A group of the proper type is created for the class
+- Admins for this class are created
+- A node is created at /
+- The Class Manager application is mounted at /
+- All chosen packages are mounted at //
+
+
+WHAT HAPPENS WHEN A USER JOINS A CLASS
+======================================
+
+- user is added to that group
+
+
+SOFTWARE STRUCTURE
+==================
+
+- each package for DOTLRN will be a small package that depends on:
+ - the main package like bboard
+ - the portlet package like bboard-portlet
+
+- so a package will be like dotlrn-bboard
+
+
+
+IMPORTANT POINTS TO CONSIDER
+============================
+
+- WOW: we might want to have a class like 6.001 be a group TYPE, with
+ each semester being a specific group of that group type. Let's
+ investigate this some more!!
+
+==> YES we will do this.
+