Grouper Developers Forum

[Tom Barton <>]

Arnaud Deman wrote:
> > I'm unsure about the customType and customTypeFieldOrList attributes. 
> > If a grouper group has a custom type whose custom attributes should be 
> > exposed in ldap, perhaps there should be a corresponding ldap 
> > objectclass that is applied to those groups and declares appropriate 
> > ldap attributes.
>
> In fact, I had the simplicity of treatment for LDAPPC in mind. With this 
> principle all the groups can be processed the same way, without  having 
> to maintain the mapping Grouper CustomType->LDAP object class. I 
> undestand that it is conceptually cleaner, but what are the practical 
> benefits of using object classes for the custom types (I am not an LDAP 
> expert).

I guess I'm not convinced that there's a good way to generically present 
one or more specific custom types that a group might have. For example, 
the grouper QuickStart package has two custom group types, "teaching" 
and "mailingList". The first has 3 custom attributes (academic-staff, 
clerical-staff, and faculty_code) and the second has 5 custom attributes 
(alias, allowAttachments, approvers, mailers, and moderated). How would 
you propose to represent a group that has teaching type, mailingList 
type, or both types?

Moreover, if a site is bothering to manage the custom attributes of a 
custom group type, there are probably one or more applications that will 
use the custom information. How will they be configured to grab the info 
from ldap? Will a generic ldappc-friendly approach be conducive to that?

Unless you have a need to provision custom group types for your work, 
perhaps it would be simplest to avoid specifying how to do so for now. 
Just leave it out, and let someone who has a real need driving them help 
us all to figure out a good way to do it.

Thanks,
Tom