Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

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

Attachment: UoBUIGroupPrivilegeResolver.java
Description: Binary data