Grouper Developers Forum

[Tom Barton <>]

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.

Tom