Grouper Developers Forum

[Tom Barton <>]

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