Grouper Users - Open Discussion List

["Dr. Loris Bennett" <>]

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