Grouper Developers Forum

[Tom Barton <>]

GW Brown, Information Systems and Computing wrote:
> --On 08 March 2005 07:22 -0600 Tom Barton 
> <>
>  wrote:
>
> > GW Brown, Information Systems and Computing wrote:
> >
> > > At the last conference call Minh reminded me that I was going to work
> > > out how much effort it would be to implement a 'Recent groups' feature
> > > which would allow the user to see groups they had created / modified
> > > recently.
> > >
> > >  From a UI perspective it should be quite straightforward - simply
> > > display a list of groups returned by an appropriate API call. I already
> > > do this in several places and can re-use some existing tiles.
> > >
> > > It probably makes sense to have a 'switch' on the 'Manage Groups' page
> > > which toggles between a display of all groups a user has privileges
> > > over, and recent items. The default view could be configurable through a
> > > properties file.
> > >
> > > It should be noted that Grouper maintains  modifytime and modifysource
> > > fields in the Grouper_group table. If another subject modifies a group
> > > you have modified, the recent items list may not be truly representative
> > > of what you have done - it will depend on whether you share
> > > responsibility for management of some groups.
> >
> >
> > An alternative approach that should be supportable with the v0.9 API is
> > for the UI to place identifiers of modified groups as members of a
> > distinguished group (more about that in a moment) with a reasonably short
> > TTL on those memberships. That provides a different and probably more
> > satisfying implementation of "recentness".
> >
> > If we do such a thing, it will be necessary to distinguish these group
> > identifiers in a members list from subgroups of the group. As subjects,
> > they would need to be of a subjectType different than 'group'. One way is
> > to allocate subjectTypes for non-resolvable identifiers such as these
> > (and possibly foreign ePPNs of people accessing signet or grouper via
> > shibboleth). Maybe an 'opaque_group' subjectType, which basically means
> > the Subject Interface should keep hands off. Colluding elements (like the
> > UI in this case) will need to know what those opaque things are, perhaps
> > dependent on where they're found.
> >
> > As to where to list a given subject's recently modified groups, how about
> > a conventionally named group in the personal group namespace? Maybe
> > '<personal_root_stem>:<username>:.:recent' (where <username> is obtained
> > from the Subject Interface, I presume). Analogous to the ".blahrc" type
> > of personal config file in a unix home directory.
> >
> > > We also talked about having a 'Favorites' feature which would
> > > effectively allow a user to 'bookmark' groups of interest and provide a
> > > quick way of accessing them. Rather than create new tables for storing
> > > such information it might be possible to implement favorites as a group
> > > of group aliases (aliases would be better than actual groups if we
> > > didn't need to maintain effective memberships). If we wanted to provide
> > > more structure we could reserve a hierarchy e.g.
> > > personal:GaryBrown:_favorites (configurable) and allow the user to place
> > > group aliases in their own hierarchy below this point.
> > >
> > > We have talked about group aliases before but not really about how they
> > > might be implemented. In the favorites example I can see that an alias
> > > could be implemented as a special group type....
> >
> >
> > If you buy the modified groups approach above, then you might like two
> > for the price of one. How about
> > '<personal_root_stem>:<username>:.:favorites' whose members are a set of
> > group ids cast as 'opaque_group' subjectType?
>
> Two for the price of one sounds good. I think the opaque_group is 
> similar to a group alias, and yes, the UI would need to treat them 
> differently from 'normal' groups - perhaps we should have a 
> GrouperGroupAlias class?
>
> If opaque_groups are implemented as a group of a specific type (like 
> stems), then is there a problem placing an opaque group directly into a 
> stem rather than as a member of a normal' group? If you think of 
> bookmarks in a web browser you have the option to organise your 
> 'favorites' into folders. By choosing a stem rather than a group as a 
> base for favorites, sub stems can represent folders.
>
> Placing opaque groups directly in stems also allows alternative browse 
> paths to be created - handy when the organisation changes structure.

My suggestion was to use a new subjectType rather than a new groupType. 
This approach requires no modification to ordinary group membership 
processing by the API, I think. A groupType in which 'members' lists are 
to be treated exceptionally sounds like it would require some 
significant code enhancements to bake in the exceptional processing. I'm 
also not clear on how that would work for an extension of a 'naming' 
type group.

The larger point I'd like to make bears on the subject interface. We 
should ensure that its design doesn't oblige every subjectType to be 
coupled with an adapter that connects to a source. We should have one or 
more "opaque" types that it recognizes are being managed elsewhere.

Regarding favorites per se, I favor an approach that requires little 
additional work for the time being. Wait until a bit later in grouper's 
lifecycle to build up such a capability if it seems warranted, and for 
now remain focused on the core functionality that we're on hook to 
deliver. The discussion so far indicates to me that the design will 
likely support one or two reasonable approaches to favorites or recents 
- I'm not worried that we'll make it too hard to do later on.

Tom