Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] "A" and "B" lists for v0.9

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] "A" and "B" lists for v0.9


Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Tom Barton <>,
  • Subject: Re: [grouper-dev] "A" and "B" lists for v0.9
  • Date: Fri, 14 Oct 2005 17:58:05 +0100

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




Archive powered by MHonArc 2.6.16.

Top of Page