[turba] Mutiple ldap database fields
Chuck Hagenbuch
chuck at horde.org
Tue Jan 20 00:36:45 UTC 2009
Quoting lenneis at wu-wien.ac.at:
>> Quoting lenneis at wu-wien.ac.at:
>>> I have looked at the latest version of the ldap driver for Turba in
>>> CVS and have noticed that there is no support for maintaining multi
>>> valued fields in an ldap database. I have modified my local install of
>>> Turba (h3-2.3.1) to support multi valued fields. Is that something of
>>> general interest and if yes, should I send a patch?
>
>> Sure, send it along. Hard to say if it's going to be accepted without
>> seeing how the patch works, of course.
>
> I was about to go into that, since I am not very familiar with Horde
> internals. So this is to solicit feedback and possibly/probably ideas
> how to make it better. This is how I have done it:
>
> - There is an additional entry in the ldap 'params' array in
> sources.php called 'ldap_attribute_params', that lists the fields we want
> to have multiple values. It looks like this, for example:
>
> 'ldap_attribute_params' => array('mail' => array('multi_value' =>
> true), 'homephone' => array('multi_value' => true, 'separator' =>
> ','))
>
> If the LDAP driver sees a fields (key) in that array that points to
> an array with an entry 'multi_value'=> true, on reading a multi
> valued attribute the individual entries are concatanated using the
> value for 'separator' in that array if set (like in 'homephone'
> above) or it uses the default from the parameter
> 'multiple_entry_separator' (like in 'mail' above) that has been
> present in the driver for a while already. This behaviour is
> unchanged form the present one except for the possibility to
> configure the string that is used to concatanate values.
>
> - On writing a field, the reverse operation is performed, we split the
> field using the separator string and write the individual entries as
> a multi valued field.
>
> 'ldap_attribute_params' could be used for more ldap specific stuff, we
> could for instance make the ldap syntax check ('checksyntax' set to
> true in params right now) configurable on a field by field basis.
>
> The main thing I am not sure about, does the above play nicely with
> the Horde form API? Of couse any other suggestions are welcome as well.
From a design/organization perspective, all of that sounds reasonable
to me, along with the idea of making checksyntax configurable through
the same mechanism.
-chuck
More information about the turba
mailing list