Subject: Grouper Developers Forum
- From: Tom Barton <>
- Subject: "A" and "B" lists for v0.9
- Date: Thu, 06 Oct 2005 18:25:31 -0400
Following is a summary of the discussion of v0.9 tasks that took place on the grouper-dev call last Wed.
We agreed that certain tasks are to be in scope for v0.9 without further discussion. These are identified in the "A" list below. Other potential work items need further discussion or clarification. These are gathered in the "B" list below. B-list tasks also need to be prioritized and slotted to a release, which might, but need not, be the 0.9 release.
Grouper v0.9 "A" list
Tasks included in the 0.9 scope of work.
A1. API & UI: performance profiling & optimization
A2. API: refactoring, richer exception set, transactional atomicity
A3. UI: adjust to and take advantage of A2, other UI refactoring
A4. API & UI: support special grouper-specific subjects. We still need to finalize the precise specs:
. should the ALL (or ANY??) token signify all authenticated subjects or anonymous users? Or should there be two such tokens, one for each?
. should GrouperSystem be a special subject and no longer a person subjectType?
. should the "wheel" group, ie, those subjectIDs permitted to act with the privilege of GrouperSystem, be just another group in the Group Registry or should it be a special one?
A5. API & UI: namespace-scoped searching
A6. API & UI: discuss initial group math design (not for implemention in 0.9)
A7. API & UI: a few bug fixes.
Grouper "B" list
Tasks for further discussion, clarification, and assignment to the 0.9 release or later releases (or consignment to /dev/null). The "B" list is not meant to be exhaustive of all tasks remaining in scope for the Grouper project, but likely does reflect those that are up sooner in the work queue.
B1. API & UI: limited support for extended group types and fields
Level 1. Sites currently can manually edit the grouper_field, grouper_typeDef, and grouper_type tables to define additional fields, their security, and associate them with existing or new group types. The API should expose the field and type structure and support assignment of multiple types to a group. The UI should enable a group type or types to be selected when creating a group, display fields in the group summary page according to the type(s) bestowed on the group, and support editing of fields according to the type(s) bestowed on the group (non-list fields on the edit group page, and list field(s) in list management pages). In addition to the API, the GrouperSourceAdapter should be extended to expose all (non-list, for now) fields of each group, taking into account the types bestowed upon it.
Level 2. API or UI support for managing the set of group fields or group types - that will continue to be done by manual editing of the underlying tables as stated above. Not for the 0.9 release.
B2. UI: improve membership management by better exposure of effective membership and subject attributes
UI users are not currently shown information that reveals how a given subject has attained effective membership in a group. Users should be presented with that information, within the constraints of their access privileges. A new "subject summary" page will list all of the specified subject's immediate & effective memberships. How immediate memberships should be presented in relation to the effective memberships that they qualify remains to be discussed. Selecting a group in this presentation cancels the session's current focus and establishes a new one at the selected group. The subject summary page will also present whatever attributes are available about that subject through the Subject API.
The subject summary page should be available from the top level menu and by some kind of link associated with checkbox lists of subjects presented in membership management pages.
Should group subjects also be presented this way, and using attributes about them exposed through the Subject API? I guess this would replace the current group summary page if so.
B3. UI: subject search improvements
Level 1. In the simple search, remove current per-subjectType restriction on searching and just search across all configured sources regardless of type. Type (and source) of search hits are returned in addition to subject name and description. Search hits are displayed with associated links that point to subjects' summary pages.
Level 2. Initial form of advanced search to be implemented. This will include selection of subjectType(s), source(s), namespace scope for group searches, and limiting search terms to selected subject attributes, provided the Subject API exposes such a capability. Attribute search restriction functionality should be discussed with the Signet team in connection with the Subject API.
B4. Better management of "effective" privileges
Grouper's default access & naming privilege implementations rely on group management capabilities, enabling a privilege to be effectively bestowed on a subject by virtue of that subject belonging to a subgroup of a group directly granted the priv. However, the access & naming interfaces presume a flat model of privilege - a subject either has it or not. This has led in 0.6 to a somewhat misleading presentation of privilegees and an inability to actually revoke privilege in some circumstances (in which the user has authority to revoke).
A related constraint is that access & naming interfaces must not expose or presume grouper-specific implementation details, in order to preserve the ability for external privilege management systems to be integrated with Grouper.
I believe Gary's on the hook to send to the list a proposed approach to B4.
B5. Determination of an XML document model for use as an integration artifact. Certainly an export artifact to drive provisioning processes, possibly as an import artifact to load groups & namespaces and assign naming & access privs.
RL Bob is on the hook to make an initial proposal along these lines.
- "A" and "B" lists for v0.9, Tom Barton, 10/06/2005
Archive powered by MHonArc 2.6.16.