Summary: | Contact information dropped when saving into LDAP and LDAP cache options cannot be set | ||
---|---|---|---|
Product: | [Applications] kdepimlibs | Reporter: | rdratlos |
Component: | kabc | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED UNMAINTAINED | ||
Severity: | normal | CC: | joerg.steffens |
Priority: | NOR | ||
Version: | 4.3 | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
Patch for kdepimlibs to fix this bug
LDAP schema required for testing of the patch using OpenLDAP |
Description
rdratlos
2010-01-11 23:59:38 UTC
There seems to be a rather simple fix for this problem. The kabc plugin ldapkio within kdepimlibs has a private AddresseeToLDIF and a data method that can be changed to support home and work address. They reside in the source file resourceldapkio.cpp. In addition, the AddresseeToLDIF and saveData methods can be adapted to support an error notification to the user if role information or home and work address have been specified for a contact. The LDAP cache configuration problem can be fixed by adapting the setCachePolicy() method in resourceldapkio.cpp, the OfflineDialog constructor in resourceldapkioconfig.cpp and the CachePolicy enum in resourceldapkio.h. I've attached a patch below to outline the required changes to the source code files. I've added several comments to the address related part of the patch to provide for a better understanding of the changed address handling strategy. In principle, the new code uses the LDAP <organization> attribute to differentiate between a business and a work contact. If this attribute contains a company name ldapkio will put the address information into an address of type Address:Work. If the LDAP attribute is empty, the address information will be stored as Address:Home. When storing the address information into LDAP, ldapkio will use either Address:HOME or Address:Work depending on the type of address the user has chosen. If a user has specified both, a work and a home address for one and the same contact, ldapkio will store the work address, if a company name has been specified in the organization field, or the home address, if organization is empty. In addition, an error notification on the GUI will inform the user that only one address type has been store in LDAP directory. The attached patch includes the corrected cache options management. In addition, the setCachePolicy() method in resourceldapkio.cpp checks now that only the cache policies that are specified by the CachePolicy enum (in resourceldapkio.h) can be set. This avoids a crash of kaddressbook. I've tested this solution under Ubuntu karmic and it works fine. I have not identified further side-effects of this patch. But I recommend some further testing. The solution seems also to be compatible to the new kaddressbook 4.4, which now limits address information to home and work address but still supports the role information. Note: As the patch is against the original source code, it contains also the patch for fixing the bugs https://bugs.kde.org/show_bug.cgi?id=218353 and https://bugs.kde.org/show_bug.cgi?id=221447. Please consider this, when including this patch into the KDE source code branch(es). Created attachment 39800 [details] Patch for kdepimlibs to fix this bug Note: As the patch is against the original source code, it contains also the patch for fixing the bugs https://bugs.kde.org/show_bug.cgi?id=218353 and https://bugs.kde.org/show_bug.cgi?id=221447. Created attachment 39801 [details]
LDAP schema required for testing of the patch using OpenLDAP
This schema adds country, mail2 and homeurl attributes to the standard
inetOrgPerson schema.
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. |