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 -r1.7 -r1.8
--- openacs-4/packages/dotlrndoc/www/doc/detailed-todo.adp 11 Nov 2001 20:57:14 -0000 1.7
+++ openacs-4/packages/dotlrndoc/www/doc/detailed-todo.adp 29 Nov 2001 02:17:34 -0000 1.8
@@ -6,7 +6,7 @@
This document details the precise steps in moving forward with dotLRN development.
-Last update: $Id$
+Last update: $Date$
Things to Do
@@ -15,29 +15,19 @@
Now:
-
-- impliment dotlrn-news and news-portlet
-
- impliment theme change in portal::config
-
- add buttons to "red box" theme
-
- impliment "unshade" icons in both themes
-
+Check left-to-finish core
Later:
-- add optional theme_id args to portal::render
-
- edit calendar_portlet::show for different views - ugly!
-
- acs-service-contract
-
- impliment dotlrn-survey and survey-portlet
-
- overview of file-storage - think about UI improvements
Ben:
-- data model for dotLRN workspace
-
- updates to applet interface as a result
+
-
data model for dotLRN workspace
+ -
updates to applet interface as a result
- managing classes, profs, etc...
@@ -140,6 +130,14 @@
"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!
+
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.4 -r1.5
--- openacs-4/packages/dotlrndoc/www/doc/index.adp 25 Oct 2001 19:51:51 -0000 1.4
+++ openacs-4/packages/dotlrndoc/www/doc/index.adp 29 Nov 2001 02:17:34 -0000 1.5
@@ -6,6 +6,7 @@
- Schedule
- Detailed TODO
+
- TODO to finish core
- Nomenclature
- Roles, Sections, and Permissions | Permission API
Index: openacs-4/packages/dotlrndoc/www/doc/left-to-finish-core.adp
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/Attic/left-to-finish-core.adp,v
diff -u -r1.2 -r1.3
--- openacs-4/packages/dotlrndoc/www/doc/left-to-finish-core.adp 14 Nov 2001 19:40:25 -0000 1.2
+++ openacs-4/packages/dotlrndoc/www/doc/left-to-finish-core.adp 29 Nov 2001 02:17:34 -0000 1.3
@@ -10,39 +10,64 @@
Portal
-- Adjust buttons on portlets as a function of capabilities
- Implement portlet locking capability.
- Implement cloning stuff.
+
-
Clean up UI on configuration page (change backlink)
+ - add roles and permissions (admin create|delete)(from dotlrn_community API)
- code review (Wednesday, 11/21, 2pm).
+
+- change theme data model to map to pages.
- Refactor some functionality as part of base portal package.
-
- Clean up UI on configuration page (change backlink)
- add acs-service-contract support.
-
- change theme data model to map to pages.
-
- add roles and permissions (admin create|delete)
- (from dotlrn_community API).
+
- update all portlets for datasource.new, user_editable_p, shadeable_p, hideable_p, sc, new procs
+
- Adjust buttons on portlets as a function of capabilities
- Remove render-element.tcl ::get_pretty_name other render cleanup
-
- Params issues
-
- code review (Monday, 11/19, 10am-12pm).
+
+
dotLRN Core
- Review exactly what the roles are
- Write up permissions procs!
-
- Move administration to community-specific pages! Duh!
+
-
Move administration to community-specific pages! Duh!
- Allow for addition of users who haven't registered yet? Check that.
- Automatically redirect single-community guests to the right location.
-
- Fix registration/deregistration bugs!
+
-
Fix registration/deregistration bugs!
- Get clubs working
- !! Figure out Relational Segments !!
+Operations
+
+- prepare staging server:
+
+-
AOLserver 3.3ad13
+ -
Oracle 8.1.7
+ -
drivers
+ -
+
+ - review existing SloanSpace site
+
+
+
+
calendar
- make group calendar work!
- each user has *ONE* personal calendar, and has access to each community calendar.
- calendar works as multi-package view in portlet.
+how this works
+
+
+- part of this involves figuring out multiple values for single parameters (instance_id in particular).
+
- every user has only ONE personal calendar
+
- every community has only ONE community calendar
+
- when a user views a community-specific page, he/she only sees that community's event.
+
- on personal calendar, they see everything
+
+
bboard
- test a bit more
@@ -60,7 +85,7 @@
FAQ
-- Clean up portlet UI (display list of FAQs)1
+
- Clean up portlet UI (display list of FAQs)
News
Index: openacs-4/packages/dotlrndoc/www/doc/permission-api.adp
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/permission-api.adp,v
diff -u -r1.1 -r1.2
--- openacs-4/packages/dotlrndoc/www/doc/permission-api.adp 24 Oct 2001 23:30:53 -0000 1.1
+++ openacs-4/packages/dotlrndoc/www/doc/permission-api.adp 29 Nov 2001 02:17:34 -0000 1.2
@@ -9,6 +9,45 @@
+
Relational Segments & Context IDs
+
+In order to make things much cleaner with respect to permissions, we
+use relational segments and context IDs. The goal of relational
+segments will be to determine groups of users to whom permissions
+are granted. The goal of context IDs will be to create a hierarchy of
+objects so that as new components are added to subcommunities,
+permissions are naturally extended in appropriate ways.
+
+
+
+For this to work, the actual privileges used throughout dotLRN and all
+of its modules must be consistent. Since permissions follow an
+inheritance path, we must make sure everything bootstraps off the
+basic read, write, create, delete, admin privileges.
+
+
+
+To better explain the situation, we want the following to happen:
+
+- Hal is a member of "Intro to Computer Science Spring 2002" group, with relationship
+type dotlrn_instructor_rel to that group.
+
- An FAQ about the Computer Science Program is created for "Intro
+to Computer Science Spring 2002", with context_id pointing to
+the course.
+
- A relational segment "Intro to CS Spring 2002 Instructors" is
+created on the "Intro to CS Spring 2002" group and
+dotlrn_instructor_rel relationship type.
+
- The privilege faq_admin exists, inheriting from
+the core OpenACS admin privilege.
+
- A permission is granted: "Intro to CS Spring 2002 Instructors"
+are given the admin privilege on the course "Intro to
+CS Spring 2002".
+
- Thus, automatically, Hal has the right to admin the FAQ,
+because the admin privilege translates to the faq_admin privilege by
+inheritance, Hal is part of the relational segment in question, and
+the FAQ in question has a context_id pointing to the course. It's BEAUTIFUL!
+
+
General Roles API
These are fairly straight-forward: