Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

I've put some screen shots and initial thoughts on Subject searching and 
subject summaries at:
<http://portal.bris.ac.uk/grouper-ui-docs/subjectcentric/>

Feedback please!

Gary

--On 06 October 2005 18:25 -0400 Tom Barton 
<>
 wrote:

> 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



----------------------
GW Brown, Information Systems and Computing