Child Pages

JIRA tasks

key	summary	assignee	status
Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Ray's plans

Development is currently split between the following tasks (in priority order):

Delivering working demos of the initial UX ideas on managing groups (within a bounded membership list) in a K2/3akai environment. (With Eli.)
Collaborate on a plan and (possible) foundation for groups-and-roles support beyond what's currently visible in out-of-the-box K2.
Continued collaborative mapping with related projects. IMS LIS should be particularly time-consuming in this round.

That second item is the murkiest and (I hope) will be our principal focus soon. I'm keeping notes on the subject at Communities vs. Sites. We've made some time to talk about it within our team, and we've also had encouraging exchanges with Michael Korcuska and Clay Fenlason. Based on the cross-project meeting at UC Berkeley on 2009-09-08, here's my current guess at how things might go:

Select a source with fairly high priority real-world needs for GnR integration. The most likely possibility is that we'll collaborate on the "simple course site" effort with Montreal HEC team members.
Working with a customer representative from that source, derive an initial series of stories. E.g., "Associate a workspace with a particular section" (a la certain flavors of Sakai 2), followed by "Automatically include general course material into section workspaces" (a la OpenSyllabus). For more general project health, it might be wise to up the priority on stories that work against Sakai-2-ish "course site silos".
Start hammering them out with pseudo-proof-of-concept UX.

Clay suggested that exploring community-centric "first-class groups" approaches is higher priority than adding groups to the current 3akai demo, but it still seems to make project management sense for us to gain hands-on familiarity with the current code base, and to find a way for development teams to contribute to Sakai 3 functionality without editing kernel code.

Working notes for GnR Services

So far, I feel comfortable keeping the basic functional vocabulary of Users, Groups, Roles, Permissions, and Resources, where Permissions and Resources are governed by application domains, and Groups and Roles are used to integrate domains. This is fairly arbitrary. Many other taxonomies are in use. All of them (including this one) fit some scenarios very tidily and other scenarios pretty clumsily. And so far I've been able to translate any of them into any of the others.

K2 / Sling / Jackrabbit application domain

Resources

K2 / Sling / Jackrabbit puts everything visible (including server-side executable scripts and internally managed users and groups, along with what programmers usually think of as "content") into JCR nodes. Nodes have properties and child nodes.

Permissions

Reflecting that "Everything's a node" approach, K2 / Sling / Jackrabbit uses a small static set of permissions, enabling old-fashioned bit-masking in access control entries:

jcr:addChildNodes
jcr:modifyAccessControl
jcr:modifyProperties - any property
jcr:read - any property
jcr:readAccessControl
jcr:removeChildNodes
jcr:removeNode

Roles

(I'm speaking functionally here – these are things that I see being used in a role-like fashion in K2, not things specially called out as instances of a "Role" class in the Jackrabbit API...)

Administrator - By default when the Jackrabbit repository is initialized, a special "administrators" group is granted all permissions at the root node. (A single special "AdminPrincipal" is granted special privileges in the code, bypassing normal access checks, but that's only one user.)
Collaborator - Managed by K2/3akai.
Viewer - Managed by K2/3akai.

Other application/service domains

AFAIK, the current Sakai 3 development teams plan to implement functionality in the K2 / Sling web framework, which means that the basic Permissions will stay put. (I suspect that other integrations will eventually be needed, but for now that's speculation and therefore ignorable.)

The current two 3akai site roles may, however, be insufficient for other ways of organizing content (other "functional lenses" on the repository):

OpenSyllabus scenarios differentiate course author and section leader.
Gradebook scenarios include a similar distinction.
Portfolio scenarios distinguish reviewing mentors from other collaborators.

Again, I don't want to prioritize this possibility at the moment – just want to acknowledge it.

Integration with external groups and roles

Here are some concepts that seem initially abstractable from use cases:

Group source

Source description - Staff, Courses, Student groups, Other institutions, OpenSocial, ...
Source vehicle - JDBC, LDAP, CM, LIS, SAML, ...

Integration points

For assigning, feeds, searches (when supportable)...

Group - hierarchical, with the group source at the root
Group + Role
Group-Tree + Role (e.g., "all department adminstrators", "all lab assistants in Chem courses this term")

We'll need to be careful here to not let our chosen terminology blind us to real-world needs and domain models. "Groups" aren't always just membership lists: the memberships are often tied to resources. (This is where it might be helpful to keep alternative taxonomies in mind.) Just as a Sakai 2 project site contains considerably more than its site membership list, an externally managed department or course or tutorial group or interest group may have other properties that need integrating: official catalog descriptions, meeting times, event calendars, etc.

Integration type

Dynamic and nonbrowsable (but cached)
Dynamic and browsable (but cached)
Mirrored
Internally managed

The first three types can support the option of being Overridable: Additions and Exclusions, Permanent or Reconcilable.