Version: (using KDE 4.3.2) OS: Linux Installed from: Ubuntu Packages The "mail" element in inetOrgPerson LDAP schema is multi-valued, allowing multiple email adresses to be stored in there. KAddressbook does display them correctly. When saving an entry with multiple email addresses, only the first one is stored in the "mail" element, the others are lost. In addition, the preferred e-mail can be lost if using mail AND mailAlias attribute. The e-mail related part of this problem was also reported earlier, but due to wrong assignment to kaddressbook it has not been solved, yet. See e. g. https://bugs.kde.org/show_bug.cgi?id=140231. Furthermore, some addressbook attributes that are used by kaddressbook and other applications (e. g. Outlook) can not be mapped to LDAP directory attributes. These are, e. g. country, birthday, office, department, homepage, nicknames.
Created attachment 39648 [details] LDAP schema required for testing of the patch using OpenLDAP This schema adds country, mail2 and homeurl attributes to the standard inetOrgPerson schema.
Created attachment 39649 [details] Patch for kdepimlibs to fix this bug
There seems to be a simple fix for this problem. The kabc plugin ldapkio within kdepimlibs has a private AddresseeToLDIF and a data method that can be changed to correctly handle several e-mail addresses in either one mail attribute or a mail and mailAlias attribute. They reside in the source file resourceldapkio.cpp. In addition, the above mentioned methods and the init method can be adapted to support additional LDAP attributes (country name, department, homepage url, birthday, nickname). For this purpose also the AttributesDialog constructor within the source file resourceldapkioconfig.cpp has to be adapted in order to allow the user to manage the new attributes. I've attached a patch to outline the required changes to the source code files. I've added several comments to the mail related part of the patch to provide for a better understanding of the mail handling strategy. In principle, the new code allows the user to store all mail addresses in either one mail or a mail and a mailAlias attribute. In the latter case, the LDAP directory will contain the preferred e-mail address in the mail attribute and all other mail addresses in the mailAlias attribute. The attached patch includes also a default mapping for three LDAP attributes in the outlook map, which is compatible to MS Outlook 2007. I've tested this solution under Ubuntu karmic and it works fine. E-mail addresses have been correctly read and stored in following cases: - mail attribute only (all mail addresses, preferred is first) - mailAlias attribute only (all mail addresses) - Different mail and mailAlias attributes (preferred address in mail, rest in mailAlias) - Same attribute for mail and mailAlias (all mail addresses, preferred is first) The new attributes are correctly set and read in the LDAP directory. Note: You need an additional LDAP schema for openldap in order to test this. - Nickname, description and (home) street are correctly mapped to LDAP attributes that are supported by Outlook 2007. I have not identified further side-effects of this patch. But I recommend some further testing. Note: As the patch is against the original source code, it contains also the patch for fixing the bug https://bugs.kde.org/show_bug.cgi?id=218353. Withoutthis fix modification of LDAP directory based contacts is not possible. Please consider this, when including this patch into the KDE source code branche(s).
I've found further bugs in the kabc part kdepimlibs with regard to LDAP (kioldap plugin). Please check https://bugs.kde.org/show_bug.cgi?id=222306. You will find there a summary patch that contains also the fixes for this bug.
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present? If noone confirms this bug for a Framework-based version of kdepim (version 5.0 or later, as part of KDE Applications 15.08 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.