Grouper Users - Open Discussion List

["Dr. Loris Bennett" <>]

Hi Chris,

Sorry, I don't think that even I understood exactly what I was
suggesting. I was thinking in terms of current grouper functionality,
but hadn't quite got things straight in my mind when I wrote the last
mail.

I had been thinking of a structure of groups representing org unit whose
members are groups representing the corresponding subordinate org units.
But obviously these member groups all have to exist in some namespace
defined by a stem hierarchy, before they can become members of groups.

Cheers

Loris 





On Fri, 2009-01-23 at 09:55 -0500, Chris Hyzer wrote: 
> Im not sure I completely understand what you are suggesting.  Can you give 
> examples of who the members of each group are?&#-1;&#-1; 
> 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
> 
-- 
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