Grouper Developers Forum

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

--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.

Gary
> Tom



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