Grouper Users - Open Discussion List

[Jon Gorrono <>]

I just noticed that not all the groups are being made: the first parent group is, but the subsequent ones are not.

I have for an example branch of the hierarchy

(level)(group_name)(subject_identifier)(subject_source_id)

1 cms:course:section:AHI:001A:A01:200610 studentidX gadget_ss_cms

2 cms:course:section:AHI:001A:A01 cms:course:section:AHI:001A:A01:200610 g:gsa

3 cms:course:section:AHI:001A cms:course:section:AHI:001A:A01 g:gsa

4 cms:course:section:AHI cms:course:section:AHI:001A g:gsa

5 cms:course:section cms:course:section:AHI g:gsa

groups are being created for 

cms:course:section:AHI:001A:A01:200610

and 

cms:course:section:AHI:001A:A01

.. but not the others

Right now I have rows for *all* of the groups at level 1 (first column) preceding any rows for groups at level 2 (and so on) in the returned query

I don't have a guess as to why :)

On Wed, Oct 31, 2012 at 4:55 PM, Jon Gorrono <> wrote:

On Wed, Oct 31, 2012 at 8:40 AM, Chris Hyzer <> wrote:

The subject_source_id for a group is not gadget_ss_cms, it is g:gsa

 

I see now.... that makes sense.

 

Im pretty sure that a group as a member in the loader needs to exist when adding as a member, though Im not sure, and I don’t know why it would need to be that way… J

 

Let me know if it works.

Yes that did it now I have groups with the same name as the folders in the hierarchy and indirect memberships reflect all the 'lower-level' memberships

I'll experiment with ordering later to test that question and let you know what I find out.

Thanks :)

 

Thanks,

Chris

 

From: Jon Gorrono [mailto:]
Sent: Tuesday, October 30, 2012 11:01 PM
To: Chris Hyzer
Cc: Nathan Weyenberg;

Subject: Re: [grouper-users] automagically creating group from stem node

 

Thanks for this suggestion and the parent/child query :)

 

 I have been trying to distill your answer and tooling around, and it must be one of my many learning disabilities, but things are definitely not going quite like Gangnam Style :)

 

The grouperLoaderQuery returns stuff like this:

 

GROUP_NAME SUBJECT_IDENTIFIER SUBJECT_SOURCE_ID

cms:course:section:AAS:010:A01:201210    gnxxxx gadget_ss_cms

cms:course:section:AAS:010:A01:201210    inxxxx gadget_ss_cms
cms:course:section:AAS:010:A01:201210    ajxxxx gadget_ss_cms
cms:course:section:AAS:010:A01    cms:course:section:AAS:010:A01:201210    gadget_ss_cms

 

and in that order (since I customized the GroupLoaderType to remove the order-by clause so I could control it)

 

The first three rows above create a group with direct members gnxxxx,inxxxx,and ajxxxx and I expected the next one to

add group cms:course:section:AAS:010:A01:201210 as a member of cms:course:section:AAS:010:A01... but even thought the former (group) is created, the latter is still just a folder with no direct/indirect memberships

 

So, does this ordering seem correct in principle?

 

Regardless, could it be that the subjobs could be running 'in parallel' and  cms:course:section:AAS:010:A01:201210 (for example) may not exist for the subjob to add it as a member to cms:course:section:AAS:010:A01 ?

 

 

Regards,

Jp

 

 

 

 

On Mon, Oct 22, 2012 at 10:29 AM, Chris Hyzer <> wrote:

Ok, if you have a table or view with your orgs and group names inside:

 

 

Then you can make a view which links up the relationships in a loader query:

 

Then just select from that view for the loader query.

 

 

Again, if you want to make it more efficient, join to grouper_groups if you can J.  Note, the groups must exist (e.g. from previous loader job which loads members into groups)

 

new GroupSave(grouperSession).assignName("stem:grpA").assignCreateParentStemsIfNotExist(true).save();

new GroupSave(grouperSession).assignName("stem:sub_stem:grpA1").assignCreateParentStemsIfNotExist(true).save();

new GroupSave(grouperSession).assignName("stem:sub_stem:grpA2").assignCreateParentStemsIfNotExist(true).save();

 

 

 

Thanks,

Chris

 

Ps. here is the text if you need to copy/paste:

 

 

CREATE TABLE `my_orgs` (

  `org_extension` varchar(100) DEFAULT NULL,

  `org_group_name` varchar(256) DEFAULT NULL

);

 

 

select my_orgs_parent.org_group_name as group_name,

       my_orgs_child.org_group_name as subject_identifier,

       'g:gsa' as SUBJECT_SOURCE_ID

from my_orgs my_orgs_parent, my_orgs my_orgs_child

where my_orgs_child.org_extension like concat(my_orgs_parent.org_extension, '%')

and my_orgs_parent.org_extension <> my_orgs_child.org_extension

 

 

CREATE

    VIEW `grouper_v2_1`.`my_orgs_v`

    AS

(select my_orgs_parent.org_group_name as group_name,

       my_orgs_child.org_group_name as subject_identifier,

       'g:gsa' as SUBJECT_SOURCE_ID

from my_orgs my_orgs_parent, my_orgs my_orgs_child

where my_orgs_child.org_extension like concat(my_orgs_parent.org_extension, '%')

and my_orgs_parent.org_extension <> my_orgs_child.org_extension);

 

 

select group_name, subject_identifier, SUBJECT_SOURCE_ID

from my_orgs_v;

 

 

select group_name, gg.id as subject_id, SUBJECT_SOURCE_ID

from my_orgs_v mov, grouper_groups gg

where mov.subject_identifier = gg.name;

 

 

From: Nathan Weyenberg [mailto:]
Sent: Monday, October 22, 2012 12:19 PM
To: Chris Hyzer

Subject: Re: [grouper-users] automagically creating group from stem node

 

Hi Chris,

 

Unfortunately, we do not have an org chart with relationships at this time and it is quite large and constantly in flux. 

 

Logically speaking it would be: 

 

A contains AXXXXXXX, 

A01 contains A01XXXX, etc.

 

The sticking point for us for trying to modify the test example was the sheer size and the naming conventions. If we had just a simple example 1 roll-up group, 1 sub stem containing two groups that were being rolled up with no include/exclude, or system of record groups I think it would be helpful. We would be able to figure out how to modify the loader jobs to work for what we needed based off of a simple example like that I believe.

 

--Nathan

On Oct 22, 2012, at 10:32 AM, Chris Hyzer wrote:

 

Do you have a database table which has your org chart relationships in it?  If so, send me the rows for the groups you want an example for, and I will send you an example.

 

Thanks,

Chris

 

From: Nathan Weyenberg [] 
Sent: Monday, October 22, 2012 11:30 AM
To: Chris Hyzer
Cc: 
Subject: Re: [grouper-users] automagically creating group from stem node

 

Hi Chris,

 

Here at the University of Wisconsin we have tried to implement Organization Hierarchies using the grouper loader, using the example you linked as a model. While we have been able to implement the proof of concept using the configurable items, we were not able to successfully modify the example to have it do what we want. Could you provide a very simple example in the documentation? 

 

What I am looking for is stem:grpA to be a group that contains stem:sub_stem:grpA1 and stem:sub_stem:grpA2 groups as members all loaded via the grouper loader. 

 

Thanks,

--Nathan

 

 

On Oct 21, 2012, at 7:42 PM, Chris Hyzer wrote:

Ok, got it.  Penn does this for orgs.  Maybe this will help you with an example:

https://spaces.internet2.edu/display/Grouper/Organization+hierarchies+via+the+grouper+loader

I believe we have one query as you have which has the people in the leaf nodes, then we have another query which link up all containers into one another...  that query is best performing if it can use the grouper_groups.id col as the subject_id to put in the group.  I think we have a DB link from our warehouse to your grouper database to make this happen (make sure the join happens on the correct side of the db link (e.g. with oracle hint) or you will be sending many rows across the link instead of a few).  Otherwise you can use the group name which might be fine since the number of groups in groups is a lot less than the number of people in groups.

Thanks,
Chris

-----Original Message-----
From: Jon Gorrono [] 
Sent: Sunday, October 21, 2012 8:00 PM
To: Chris Hyzer
Cc: 
Subject: Re: [grouper-users] automagically creating group from stem node

ok, I was trying to pack as much into the smallest question possible I guess :)

The simple view I have returns something like:

group_name, subject_id, subject_source_id
'cms:course:section:AHI:001B:A01:200501', '0003482', 'ss_cms'
'cms:course:section:AHI:001B:A02:200501', '0008892', 'ss_cms'

So this creates a group '200501' nested in the folder structure
'cms:course:section:AHI:001B:A01' with the member with subject_id
'0003482'

...and a group '200501' nested in the folder structure
'cms:course:section:AHI:001B:A02' with the member with subject_id
'0008892'


Logically this folder structure could be construed to indicate that
the folder 'cms:course:section:AHI' contains both '0003482' and
'0008892' as indirect members... I can see that you might not want
that to be true as a general steadfast rule, but I thought that there
might be a way get folders to inherit subfolder memberships with out a
specific assignment buy the loader.

So you're saying that in order to do that I should have another row in
the result (or a different query) to accomplish that? ... a query row
that ties both id's with the shorter stem?


On Sat, Oct 20, 2012 at 5:30 AM, Chris Hyzer <> wrote:

I dont know exactly what you are asking, but I think the answer is yes :)

 

Your query results can be groups as members... you could have multiple queries running after one another to cascade correctly.  We do this at Penn.   If you want to give a more detailed example I could explain a little better

 

thanks,

Chris

________________________________________

From:  [] on behalf of Jon Gorrono []

Sent: Friday, October 19, 2012 6:15 PM

To: 

Subject: [grouper-users] automagically creating group from stem node

 

I probably have all the terminology wrong here but...

 

my question, put right up front, is .... when provisioning a bunch of

stems+groups and members(hips) with the loader is there a way to make

the stem-nodes (folders?) be groups with indirect members made from

the groups' members below that node in the (folder/group/stem)

hierarchy?

 

example:

 

http://server/grouper-ws/servicesRest/json/v2_1_001/groups/cms%3Acourse%3Asection%3AAHI%3A001B%3AA01%3A200501/members

 

That returns a nice json list of members of a leaf node which is a

group defined via the loader job as

'cms:course:section:AHI:001B:A01:200501'

(that is Section A01 of the Courseoffering AHI 001B for the first term of 2005)

 

But I assumed that the intermediate folders would also be addressable

and members(hips) inherited, maybe by throwing some switch somewhere

 

So logically 'cms:course:section:AHI:001B' might contain all the

members of all the sections in all a terms for AHI 001B ... instead

this returns a groupNotFound... the intermediate 'folder' doesn't seem

to be addressable:

 

http://server/grouper-ws/servicesRest/json/v2_1_001/groups/cms%3Acourse%3Asection%3AAHI%3A001B/members

 

(actually expected 'members' to return 0 and 'memberships' to return a

sum of the groups below as indirect members)

 

Regards,

Jp

 

...

 

 

--

Jon Gorrono

PGP Key: 0x5434509D -

http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index}

http{middleware.ucdavis.edu}

-- 
Jon Gorrono
PGP Key: 0x5434509D -
http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index}
http{middleware.ucdavis.edu}

 

Nathan Weyenberg

UW-Madison DoIT - Middleware

 

Nathan Weyenberg

UW-Madison DoIT - Middleware

 

 

--
Jon Gorrono
PGP Key: 0x5434509D - http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index}
http{middleware.ucdavis.edu}

--
Jon Gorrono
PGP Key: 0x5434509D - http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index}
http{middleware.ucdavis.edu}

--
Jon Gorrono
PGP Key: 0x5434509D - http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index}
http{middleware.ucdavis.edu}