Grouper Users - Open Discussion List

[Chris Hyzer <>]

> - I can't see *_count in the logs at all - what log4j properties do I
> need?

These are in the grouploader_log table, one entry for each run of each loader 
job

> I have done some more testing and found the following behaviour.

Thanks for thorough testing

> - If this group and the user is deleted from the database, both the
> group and the user remain in grouper

Hmm... this is kind of a tough problem... I would need to know that a group 
which is no longer in the loader needs to have its membership list deleted... 
this is not solved in any release yet, would require some thought and design. 
 Currently any group in the returned sql is managed by that loader run, but 
now we either need to remember that a group was associated with a loader job, 
or have another way to identify it (maybe the loader job have an attribute 
which identifies a pattern of group names, e.g. 
grouperLoaderGroupListPattern: myschool:orgs:%   (regex would be nice, but it 
needs to be efficiently queriable with SQL).  Then I guess any groups that 
match that pattern which are not in the returned SQL would have their 
memberships removed.  I think we would need to remove membership and not 
delete the group so the group name and ID are reserved in the namespace (e.g. 
if another group is using one of the generated groups as a composite).  Maybe 
deleting the empty groups could be a manual process?  Or maybe there is an 
option whether you want to delete the group or just remove membership?

Does that work for you?

Regards,
Chris