Grouper Users - Open Discussion List

[Loris Bennett <>]

On Thu, 2008-10-16 at 06:42 -0400, Chris Hyzer wrote:
> > - 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?

The pattern idea sounds good. Because we want to populate a whole tree
of folders with grouploader-groups and we would need to be able to
specify something like:

        myschool:orgs%:auto

so that all 'auto' groups anywhere in the hierarchy below
'myschool:orgs' could be addressed. (BTW, is there any mechanism
available to prevent a group called 'auto' being created manually?)

Deleting empty groups my hand would be OK for us. We are already a
little chicken about the idea of updating our basic org groups 100%
automatically and hoping that nothing breaks in the composite groups.
Ideally we would like to generate some sort of summary of the changes
before these are actually propagated. This would give us an overview of
the changes occurring and enable us to anticipate the effects on derived
groups.

What sort of timeline would you be looking at, if you were to add such a
feature?

Regards

Loris

> 
> Regards,
> Chris
> 
>