Index: openacs-4/packages/dotlrndoc/www/doc/detailed-todo.adp
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/Attic/detailed-todo.adp,v
diff -u -N
--- openacs-4/packages/dotlrndoc/www/doc/detailed-todo.adp 29 Nov 2001 02:17:34 -0000 1.8
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,145 +0,0 @@
-<%= [dotlrn_header "dotLRN Documentation: Detailed ToDo"] %>
-
dotLRN Detailed Todo
-part of dotLRN Documentation
-
-
-This document details the precise steps in moving forward with dotLRN development.
-
-
-Last update: $Date: 2001/11/29 02:17:34 $
-
-
-
Things to Do
-Arjun:
-
-
-Now:
-
-Check left-to-finish core
-
-
-Later:
-
-
-
-
-Ben:
-
--
data model for dotLRN workspace
- -
updates to applet interface as a result
- - managing classes, profs, etc...
-
-
-
-
-both:
-
-- cloning discussion
-
- workspace discussion
-
-
-Portals Enhancements - Urgent
-
-
-- 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).
-
-Works! In BETA Oct. 24
-
-- 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.
-
-
Perms scheme complete
-
-
Done except for parts that depend on "cloning", "locks", etc. One portal proc (create) uses user_id. In ALPHA Oct. 24
-
-
-
-Portals Enhancements - Less Urgent
-
-
-- layout change - AKS: thinging about interaction with below
-
- "cloning" - 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.
-
-
- "locks" - 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.
-
-
-
- "available PEs" - 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.
-
-
AKS: Adding portlet to already registered users issue.
-
-
-
-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).
-
-
-
-
-Calendar
-
-File Storage
-
-Old Items
-
-
-- Make all explicitly-sourced Tcl scripts into procs. Fix
-templates.
-
-Two tcl scripts are explicitly sourced:
-www/render-element.tcl and www/place-element.tcl
-which is the configuration analogue of the former. Users of the portal
-package have no knowledge of these scripts, they only use the
-Tcl API. I've looked at this, and I don't see how it can be changed at
-the moment because of the way the templating system works. I'm moving
-on.
-
-- fix the path to template finding for each portal element (no symlink!)
-
-- fix the parameter setting (specifically in bboard)
-
-
Fixed in all portlets.
-
-- "available" portlets: data-model, Tcl API, and web pages
-- implement shade, remove, edit, link from title
-
-
-- impliment dotlrn-news and news-portlet
-
- impliment theme change in portal::config
-
- add buttons to "red box" theme
-
- impliment "unshade" icons in both themes
-
- add optional theme_id args to portal::render
-
- edit calendar_portlet::show for different views - ugly!
-
-
-
-
-
-<%= [dotlrn_footer] %>
Index: openacs-4/packages/dotlrndoc/www/doc/long-term-todo.adp
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/Attic/long-term-todo.adp,v
diff -u -N
--- openacs-4/packages/dotlrndoc/www/doc/long-term-todo.adp 8 Nov 2001 20:08:08 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,25 +0,0 @@
-<%= [dotlrn_header "dotLRN Documentation: Long Term ToDo"] %>
-dotLRN Long-Term Todo
-part of dotLRN Documentation
-
-
-This document mentions long-term todos.
-
-
-
-
dotLRN Core
-
-
-
-
-
Events w/ eCommerce
-Furfly is providing an estimate.
-
-
-
-
Research Module
-
-
-<%= [dotlrn_footer] %>
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
--- openacs-4/packages/dotlrndoc/www/doc/schedule.adp 25 Oct 2001 19:51:51 -0000 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,55 +0,0 @@
-<%= [dotlrn_header "dotLRN Schedule"] %>
-dotLRN Schedule
-by Ben Adida, part of dotLRN Documentation.
-
-
-The schedule has been completely revamped due to events of early September.
-
-
-
-
October 29th
-
-- fully functional New Portal Architecture
-
- finalized permissioning architecture
-
- finalized dotLRN applet interface (acs-service-contract)
-
- basic dotLRN applets:
-
- - bboard
-
- faq
-
- file-storage (old UI)
-
- calendar
-
- - basic class and club administration:
-
- - creation, editing
-
- membership, setting of roles (instructors, tas, admins...)
-
-
-
-November 5th
-
-- Demo of functional dotLRN Core
-
- implementation of basic permissioning system (but not complete)
-
- implementation of personal portal page
-
- mostly functional dotLRN applets including:
-
- - bboard
-
- file storage (old UI)
-
- faq
-
- calendar
-
- community information (roster, etc...)
-
-
-
-November 12th
-
-
-November 19th
-
-November 26th
-
-December 3rd
-
-<%= [dotlrn_footer] %>