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: Chris Hyzer <>
  • To: Tom Barton <>
  • Cc: Grouper Dev <>
  • Subject: RE: [grouper-dev] grouper membership loader
  • Date: Mon, 28 Apr 2008 16:14:02 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

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


Archive powered by MHonArc 2.6.16.

Top of Page