Grouper Users - Open Discussion List

[Chris Hyzer <>]

Im not sure I completely understand what you are suggesting.  Can you give 
examples of who the members of each group are?  Are they other groups (lower 
in the hierarchy) or lists of people?  Is there a new concept introduced 
here, or are we using existing grouper concepts?

Thanks,
Chris

> -----Original Message-----
> From: Dr. Loris Bennett 
> [mailto:]
> Sent: Wednesday, January 21, 2009 8:08 AM
> To: Grouper Users Mailing List
> Subject: Re: [grouper-users] RE: [grouper-dev] auto-creating "include"
> and "exclude" groups based on group type hook
>
> After talking to some colleagues, I think maybe I am approaching the
> problem of "roll-up" or "recursive all" from the wrong angle.
>
> Up to now I had envisaged importing data from a source of records into
> grouper in the following manner:
>
> The actual hierarchy is comprised of folders e.g.
>
>         uni:school:computing_centre:identity_manangement (a folder)
>
> Each folder contains a groups of, say, employees associated with that
> point in the org structure, e.g.
>
>         hr-data:uni:school:computing_centre:identity_manangement:sor (a
>         group)
>
> Points in the hierarchy that are not leaves also contain a group
> containing all the members beneath that point, e.g.
>
>         hr-data:uni:school:computing_centre:sor
>         hr-data:uni:school:computing_centre:sor_all
>
> What I now think I should be doing is to set up most of the hierarchy
> as
> groups of groups, e.g.
>
>         hr-data (a folder)
>         hr-data:uni (a group, all employees of the university)
>         hr-data:uni:sor (a group, top-level employees, member of )
>         hr-data:uni:computing_centre (a group, all computer centre
>         employees)
>         hr-data:uni:computing_centre:sor (a group, all top-level
>         computer centre employees)
>         hr-data:uni:computing_centre:identity_management (a group, all
>         members of the identity management group, member of
>         hr-data:uni:computing_centre)
>         hr-data:uni:computing_centre:identity_management:sor (a group,
>         top-level members of the identity management group, member of
>         hr-data:uni:computing_centre:identity_management)
>
> This now seems to me the obvious way to do things, in particular since
> no roll-up groups are needed. However, some people on the list seemed
> to
> thing that roll-up groups would be useful when I mentioned wanting
> them.
>
> How are others using groups as opposed to stems for structuring
> hierarchies?
>
> Regards
>
> Loris
>
>
> On Wed, 2009-01-21 at 13:22 +0100, Dr. Loris Bennett wrote:
> > OK, that sounds fine.  My client should be able to create a loader
> group
> > at each node in my org structure automatically, since I can now save
> > group details, right?
> >
> > However, I wonder whether it wouldn't be easier for me to just add
> the
> > membership to all higher nodes when I set up the table for grouper
> > loader. I.e. instead of just writing the system of record groups
> >
> >         uni:computer_centre:identity_management:sor 12345
> >         uni:computer_centre:hpc:sor 56789
> >
> > I could add
> >
> >         uni:computer_centre:identity_management:sor 12345
> >         uni:computer_centre:all 12345
> >         uni:all 12345
> >         uni:computer_centre:hpc:sor 56789
> >         uni:computer_centre:all 56789
> >         uni:all 56789
> >
> > and let grouper loader setup the rollup 'all' groups for me.
> >
> > This is obviously going to bloat the table quite a lot as there could
> be
> > an average of about 5 levels of hierarchy per subject, so I am a
> little
> > worried about performance. Currently 454 subjects end up as 2320 rows
> in
> > the grouper loader table and tale over 7 minutes to deploy.
> Ultimately I
> > shall be looking at around 35000 subjects.
> >
> > How do you suppose this would scale compared with the approach with
> > individual loader groups?
> >
> > I suppose ideally the loader could be configured to add the
> memberships
> > in higher levels of hierarchy automatically. A feature for 1.5 maybe?
> >
> > Regards
> >
> > Loris
> >
> > On Tue, 2009-01-20 at 13:16 -0500, Chris Hyzer wrote:
> > > Yes, I understand now.  My suggestion for this is to create a
> loader group for this.
> > >
> > > You can do this directly against the grouper_groups table if you
> like.  E.g. the query will be:
> > >
> > > select gg.id as subject_id from grouper_groups gg where gg.name
> like 'uni:%sor'
> > >
> > > Sound good?
> > >
> > > Thanks,
> > > Chris
> > >
> > > > -----Original Message-----
> > > > From: Loris Bennett 
> > > > [mailto:]
> > > > Sent: Tuesday, January 20, 2009 3:41 AM
> > > > To: Chris Hyzer
> > > > Cc: Grouper Users Mailing List
> > > > Subject: RE: [grouper-dev] auto-creating "include" and "exclude"
> groups
> > > > based on group type hook
> > > >
> > > > Hi Chris,
> > > >
> > > > Maybe I am missing something, but GRP-178 seems to be just about
> > > > include/exclude. I was thinking more along the lines of the
> following:
> > > >
> > > > A group can be defined as the union of all the groups whose names
> match
> > > > a given pattern. So if I have
> > > >
> > > >         uni:computer_centre:sor
> > > >         uni:computer_centre:admin:sor
> > > >         uni:computer_centre:hpc:sor
> > > >         uni:computer_centre:identity_management:sor
> > > >
> > > > I would then have
> > > >
> > > >         uni:all defined by uni:%sor
> > > >         uni:computer_centre: all defined by
> uni:computer_centre:%sor
> > > >
> > > > I have tried to do something similar with requireInGroups, e.g.
> > > >
> > > >         grouperIncludeExclude.requireGroup.name.0 =
> > > >         testRequireInGroupAttribute
> > > >         grouperIncludeExclude.requireGroup.attributeOrType.0 =
> type
> > > >         grouperIncludeExclude.requireGroup.group.0 =
> sources:fub:%sor
> > > >         grouperIncludeExclude.requireGroup.description.0 = If
> value is
> > > >         true, members of the overall group must be in SAPHR (in
> the
> > > >         sources:fubb:%sor group).  Otherwise leave this value not
> > > > filled
> > > >         in.
> > > >
> > > > but the pattern functionality doesn't seem to be there.
> > > >
> > > > Regards
> > > >
> > > > Loris
> > > >
> > > > On Mon, 2009-01-19 at 09:53 -0500, Chris Hyzer wrote:
> > > > > I believe everything requested is done in 1.4.  Please try it
> out and
> > > > let me know what you think.
> > > > >
> > > > > https://bugs.internet2.edu/jira/browse/GRP-178
> > > > >
> > > > >
> > > >
> https://wiki.internet2.edu/confluence/display/GrouperWG/Include+exclude
> > > > +and+require+groups
> > > > >
> > > > > Note, due to the nature of include/exclude, custom
> types/attributes,
> > > > and how configurable it is, it is a bit complicated... feel free
> to
> > > > edit this wiki page or give any suggestions on how to make it
> easier to
> > > > use (including changes to documentation grouper.properties file).
> Let
> > > > me know if you have questions/issues
> > > > >
> > > > > Chris
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Loris Bennett 
> > > > > > [mailto:-
> berlin.de]
> > > > > > Sent: Monday, January 19, 2009 9:41 AM
> > > > > > To: Tom Barton
> > > > > > Cc: Chris Hyzer; Grouper Dev
> > > > > > Subject: Re: [grouper-dev] auto-creating "include" and
> "exclude"
> > > > groups
> > > > > > based on group type hook
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Did the feature below make it into Jira? I'd would be
> interested on
> > > > the
> > > > > > timeline for any implementation, so that I know whether to
> just
> > > > wait or
> > > > > > come up with a workaround.
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > Loris
> > > > > >
> > > > > > On Fri, 2008-10-24 at 09:41 -0500, Tom Barton wrote:
> > > > > > > Loris Bennett wrote:
> > > > > > > > I mentioned the idea of having a "orgAll" and
> "orgRecursiveAll"
> > > > to
> > > > > > > > distinguish between the group all the members associated
> with a
> > > > > > > > particular org unit and the group of members associated
> with a
> > > > > > > > particular org unit or one of its descendants.
> > > > > > > >
> > > > > > > > Could this also be realized in this context.
> > > > > > >
> > > > > > > Good point. In fact, U Chicago wrote a java util to create
> an org
> > > > > > > hierarchy in grouper from an SoR source with include,
> exclude,
> > > > and
> > > > > > > rollup groups, exactly as you describe. So "+1" to your
> feature
> > > > > > request.
> > > > > > >
> > > > > > > Tom
> > > > >
> > >
> --
> Dr. Loris Bennett (Mr.)
> Freie Universität Berlin
> ZEDAT - Zentraleinrichtung für Datenverarbeitung / Computer Center
> Compute & Media Service
> Fabeckstr. 32, Room 221
> D-14195 Berlin
> Tel ++49 30 838 51024
> Fax ++49 30 838 56721
> Email 
> 
> Web www.zedat.fu-berlin.de