Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] 'Recent groups' feature in UI

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] 'Recent groups' feature in UI

Chronological Thread 
  • From: Tom Barton <>
  • To:
  • Subject: Re: [grouper-dev] 'Recent groups' feature in UI
  • Date: Tue, 08 Mar 2005 07:22:02 -0600

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?


Archive powered by MHonArc 2.6.16.

Top of Page