Grouper Developers Forum

[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 
> 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?

Tom