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: "GW Brown, Information Systems and Computing" <>
  • To:
  • Subject: Re: [grouper-dev] 'Recent groups' feature in UI
  • Date: Tue, 08 Mar 2005 13:51:02 +0000



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




Archive powered by MHonArc 2.6.16.

Top of Page