Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Re: [grouper-users] Ldappc and Grouper privileges

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Re: [grouper-users] Ldappc and Grouper privileges

Chronological Thread 
  • From: Arnaud Deman <>
  • To: Tom Barton <>,
  • Subject: Re: [grouper-dev] Re: [grouper-users] Ldappc and Grouper privileges
  • Date: Mon, 12 Jan 2009 10:16:02 +0100
  • Authentication-results:; dkim=none (no signature) header.i=unknown; dkim-adsp=none
  • Organization: GIP RECIA

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:

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.



Archive powered by MHonArc 2.6.16.

Top of Page