Grouper Developers Forum

[Chris Hyzer <>]

> >
> > 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), 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), 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.

Chris