[turba] Mutiple ldap database fields

[lenneis at wu-wien.ac.at]

Chuck Hagenbuch:

> 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.

regards,
 


-- 

Joerg Lenneis

email: lenneis at wu-wien.ac.at