Grouper Users - Open Discussion List

[Chris Hyzer <>]

Im not exactly sure what the configuration of the loader would look like if 
we had this feature, if someone wants to give me a detailed description of 
how it would work (what the configuration and output would be), that would 
help me clear it up.  I think if we had parentId, we would also need that id 
in the group/stem somewhere, right?  I get all SQL then process, but I would 
like to order the SQL results to process in order and not keep things in 
memory, so it seems a little complicated...

Yes, at Penn we have hierarchical orgs, and I think I will put that into 
grouper since not a lot of people are using the existing flat structure 
yet...  this can be done with the existing loader with the following:

1. make a SQL function which goes from org_code to group_name:  (just a loop 
which goes until parent is null, appending)
2. I will probably make a view from this on org_code to group_name (and maybe 
parent also), and periodically dump this to a table, for performance.  I 
don’t think we have custom loader jobs, but maybe I can create this concept, 
so the loader can dump this to a table for me.  Or maybe just a hook on the 
existing loader job, which syncs it up.
3. In my query to the loader, just join org code with the expanded group 
name, since the grouper loader query for group of groups does not require 
each group to be in the same parent stem
4. Make another grouper loader job to do the rollups based on this org_code 
to group_name table... (as Tom said, it includes all orgs in the org).

Anyways, I don’t think this is that inconvenient... so I wonder how much a 
parentId in the loader would buy...  well, I will try to get this working at 
Penn and document it, and see where the pain points are...

Thanks,
Chris

> -----Original Message-----
> From: Richard James 
> [mailto:]
> Sent: Monday, March 16, 2009 12:06 PM
> To: 'Tom Barton'; Chris Hyzer
> Cc: 
> ;
>  Grouper Users Mailing List
> Subject: RE: [grouper-users] Stems and Group Members
> 
> I would also express my interest in this feature. We now have a
> hierarchy set up within Grouper for the University, the way we have
> done it is by having a folder for each school/faculty, then within this
> folder have an individual group for each of the departments within the
> school, so for ISS it's similar to the below;
> 
> 
> Newcastle University (Parent Stem)
> >>>>>Central Services (Stem)
> >>>>>>>>>>ISS (Stem)
> >>>>>>>>>>>>>ISS All (Group, using grouperLoader)
> >>>>>>>>>>>>>Middleware Team (Group)
> >>>>>>>>>>>>>Unix Network Team (Group)
> >>>>>>>>>>>>>Information Delivery Team (Group)
> 
> The initial set up of this was quite painful at times, so I think as
> Loris has suggested, if you were able to give a table of the org_id and
> parent_org_id to create the initial hierarchy of folders it would be a
> very useful feature.
> 
> Regards
> 
> Richard
> 
> 
> >-----Original Message-----
> >From: Tom Barton 
> >[mailto:]
> >Sent: 16 March 2009 15:36
> >To: Chris Hyzer
> >Cc: 
> >;
> > Richard James; Grouper Users Mailing
> >List
> >Subject: Re: [grouper-users] Stems and Group Members
> >
> >Chris Hyzer wrote:
> >>> Isn't it that case that "grouperLoaderQuery" actually creates
> >multiple
> >>> groups, whereas "grouperLoaderGroupQuery" just allows the display
> >name
> >>> to be set?
> >>
> >> Ah yes, you are right.
> >>
> >>> At first reading I thought I should also try something like that,
> >since
> >>> being able to use a single select like that is quite elegant.
> >However,
> >>> I am also keen to keep the hierarchy, rather than having all the
> >groups
> >>> in one folder.
> >>>
> >>> Chris, would it be feasible to tweak Grouper so that it can make an
> >org
> >>> structure pop into existence as a hierarchy of folders, given a
> table
> >>> containing org_id and parent_org_id information? Looks like it
> might
> >be
> >>> a useful feature for Penn ;-)
> >>>
> >>
> >> We could consider that at some point...  so you would want an org to
> >> be a folder and a group inside right?  And if an org has a parent,
> >> put it in its folder...  hmmm
> >
> >+1 on that feature request. A "bushy" form in addition to the "flat"
> >form. Sometimes you want one, sometimes the other.
> >
> >Also, an org folder might contain two groups: the people at that node
> in
> >the org hierarchy, and a rollup group of all people at a subordinate
> >node in the hierarchy. That one probably just consists of subgroups,
> no
> >direct non-group Subjects.
> >
> >Tom