Subject: Grouper Developers Forum
- From: Tom Barton <>
- Subject: Re: [grouper-dev] 'Recent groups' feature in UI
- Date: Tue, 08 Mar 2005 09:08:37 -0600
GW Brown, Information Systems and Computing wrote:
--On 08 March 2005 07:22 -0600 Tom Barton
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
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
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.
- 'Recent groups' feature in UI, GW Brown, Information Systems and Computing, 03/08/2005
Archive powered by MHonArc 2.6.16.