store multiple email addresses as separate 'mail' attributes in LDAP

My Turba uses an LDAP backend, and I wondered how people cou

Sun, 30 Jan 2011 15:29:54 +0000

My Turba uses an LDAP backend, and I wondered how people could have more than one email address. Obviously, LDAP supports multiple 'mail' attributes per inetOrgPerson and when setting 'allow_multi' => true in turba/config/attributes.php, they are also treated as separate email addresses and each 'mail' entry results in a separate mailto-link in Turba. However, when editing the email field, there is a comma-separated list of addresses which is written back into LDAP *as is*. This causes problems, because, for example, it's not possible any more to do an LDAP query with "(mail=address1@host.com)". Instead, the LDAP backend - just as it converts multiple 'mail' attribute values to a PHP array - should act the same when saving, i.e. converting the PHP array (or the comma-separated string) into multiple LDAP attributes.

Try using the 'emails' instead of 'email' attribute.

Sun, 30 Jan 2011 17:11:57 +0000

Try using the 'emails' instead of 'email' attribute.

The behavior of using 'emails' is identical to using 'email'

Sun, 30 Jan 2011 17:20:56 +0000

The behavior of using 'emails' is identical to using 'email' with 'allow_multi'=true for me, i.e. multiple addresses get stored as a comma-separated string in the 'mail' attribute in LDAP.

The problem is that: 1) The email form field always returns

Fri, 01 Jul 2011 17:24:30 +0000

The problem is that: 1) The email form field always returns a single value, though we could of course split this up again, or add an option to return an array instead. 2) But more important, there isn't any way in Turba to store one field into several attributes. We do have composite fields, but these store in a *fixed* number of *different* attributes, not in a *variable* number of the *same* attribute. There is no infrastructure for that at all, so this is a larger undertaking.

Seeing the first alpha releases of the horde apps, I was won

Sat, 07 Jul 2012 10:58:50 +0000

Seeing the first alpha releases of the horde apps, I was wondering if this is gonna be addressed in the next version or not. Multiple emails is a must for many many people I guess. Currently, it is the biggest limitation I have to live with when using horde....

> 1) The email form field always returns a single value, tho

Wed, 02 Nov 2016 21:42:40 +0000

> 1) The email form field always returns a single value, though we > could of course split this up again, or add an option to return an > array instead. > 2) But more important, there isn't any way in Turba to store one > field into several attributes. We do have composite fields, but these > store in a *fixed* number of *different* attributes, not in a > *variable* number of the *same* attribute. There is no infrastructure > for that at all, so this is a larger undertaking. Is this necessary at all? As far as I can say, the emails (multi_value) field works fine with IMP and ActiveSync. It works with ActiveSync in the expected way, the first three email addresses from emails are provided as email1, email2 and email3 to an activesync device and read this way from the device. (three email address are the limit of activesync) this happens ins turba/lib/Driver.php at line 2690: case 'emails': $address = 1; foreach (explode(',', $value) as $email) { while ($address <= 3 && $message->{'email' . $address . 'address'}) { $address++; } if ($address > 3) { break; } $message->{'email' . $address . 'address'} = $email; $address++; } break; A smiliar code snippet is there for vcards. For LDAP I find the "array_merge" inside the _read function off Ldap.php. In funtion _write, there is nothing. My suggestions: 1) generic version at line 304: if source is comma seperated array and target mutli value for i in array ... this one might be dangerous with other fields als children/child 2) Or a hardcoded version just for "emails" somehow ugly but works and no side effects 3) in backends.local.php the opportunity/example for 2) My php skills are just not good enough at the moment :(