Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] grouper membership loader

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] grouper membership loader


Chronological Thread 
  • From: Tom Barton <>
  • To: "GW Brown, Information Systems and Computing" <>
  • Cc: Chris Hyzer <>, Grouper Dev <>
  • Subject: Re: [grouper-dev] grouper membership loader
  • Date: Tue, 29 Apr 2008 12:03:40 -0500

To clarify a bit, my concern is focused on the narrow issue of potentially conflicting ways that the membership of a given group is managed. We already have a mechanism to manage that, and I didn't recognize a new requirement that it didn't already meet. I'd prefer to avoid having to build special infrastructure within the grouper api that would be necessary to enable loaders to do whatever they need to do, however they need to do it. I suspect that such measures would tend to reduce the freedom otherwise open to loader designers. So, I don't propose anything that would interfere with your scenario, Gary, but neither do I propose anything that might promise to make it easier somehow.

Tom

GW Brown, Information Systems and Computing wrote:


--On 28 April 2008 16:14 -0400 Chris Hyzer
<>
wrote:

>
> Right, but the group will still need to be flagged somehow so that
> UI/GSH/WS knows it is dynamic and doesnt edit it [only to be
> overwritten later] (e.g. restrict the editing of it via hooks). So
> the group will need a "type" or an "attribute" or external table or
> config, right? I don't see how there can be overlap, how a static
> group could be dynamically controlled and still be "static" (i.e.
> allow manual memberships directly assigned)...

Do you think UPDATE priv can be used for this purpose? Ie, ensure that
loaders identify themselves as such, so that they alone can manage
membership. Just as we do for "human loaders". Turn this into a
documentation & deployment feature rather than an API feature?


Yeah, that's fine, I think that is another way to "flag" the group as
dynamic, by having a priv (though wheel group members might not be
restricted but maybe not a huge deal)
My intention behind <http://viewvc.internet2.edu/viewvc.py/grouper-ui/java/src/edu/internet2/middleware/grouper/ui/UIGroupPrivilegeResolver.java?root=I2MI&view=markup> was to allow disabling of editing in the UI for GrouperSystem / wheel group members (see attached uob implementation). I also wanted to differentiate which aspects of a group might be managed. In general, I create local admin groups for courses, departments and faculties - and assign privileges to these groups, but I don't assign members in the loader - part of the reason we need Grouper is we don't have these groups elsewhere already!

So, in effect I want to use the loader to create a consistent set of groups even if I can't populate all the memberships. I might also want to add additional types to loader maintained groups and not have the loader remove those types i.e. it should only manage the types and attributes it is coded to deal with. I'm not convinced I can get the level of control I want through the Access privilege mechanism.

Obviously my approach only works in the UI and does not apply to grouper-ws or gsh. I don't yet have a need for it with grouper-ws. Access to gsh at Bristol is likely to be pretty restricted, but, in any case, there may sometimes be the need to tweak a managed group when a change cannot wait for the next loader invocation.

Ultimately, hooks would be the way to go. A loader might not register the same ones as a UI.

, or a group description comment or
structure or document or standard. So I think we agree that the there
are three group types and that they are mutually exclusive: composite,
manually managed, auto-managed. However, Gary did mention one point that
the auto-managed group could have a group added as a member (perhaps
manually),
Some might be added by the loader. As described above, in some cases my loader will create groups where it does not then manage the membership of the group so a user is free to add any subject as a member
and the auto-process would not remove it... lots of
interesting possibilities. :) And if we have membership metadata
eventually then we could have more overlap. Though if group metadata is
bad for performance, then membership metadata might be also.
one to one joins (or extending the grouper_memberships table might be ok but if you were to have one-many lookups for memberships I think that might be very slow.

Chris





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

begin:vcard
fn:Tom Barton
n:Barton;Tom
org:University of Chicago;Networking Services & Information Technology
adr;dom:1155 E. 60th St.;;Rm 309, 1155 Bldg;Chicago;IL;60637
email;internet:
title:Sr. Director - Integration
tel;work:+1 773 834 1700
version:2.1
end:vcard




Archive powered by MHonArc 2.6.16.

Top of Page