Grouper Developers Forum

[Arnaud Deman <>]

Hi Tom,

Tom Barton a écrit :
> 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?
I made a mistake in the schema: the attribute CustomType should be multi 
valued, and my idea was to use a representation like this:
customType:teaching
customType:mailingList
customTypeFieldOrList:academic-staff$value
customTypeFieldOrList:clerical-staff$value
customTypeFieldOrList:faculty_code$value
customTypeFieldOrList:alias$value
customTypeFieldOrList:allowAttachments$value
customTypeFieldOrList:approvers$value
customTypeFieldOrList:mailers$value
customTypeFieldOrList:moderated$value


I realize there is problems with this approach : the values can't be 
used directly and the types can't have a field with the same name, so I 
agree with you:  custom LDAP classes may be used for the custom 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.
In fact we have this need. For instance, we would like to use the type 
to differentiate groups of teachers and groups of students. For now, we 
don't need the custom type fields but I think this will come quickly.

Regards,
Arnaud.

> Thanks,
> Tom