6.0.0-beta1
7/18/25

[#8595] 1-click add_address from message display fails with LDAP driver
Summary 1-click add_address from message display fails with LDAP driver
Queue Turba
Queue Version 2.3.2
Type Bug
State Resolved
Priority 1. Low
Owners jan (at) horde (dot) org
Requester andydorman (at) comehome (dot) net
Created 09/22/2009 (5778 days ago)
Due
Updated 01/13/2010 (5665 days ago)
Assigned
Resolved 09/25/2009 (5775 days ago)
Github Issue Link
Github Pull Request
Milestone 2.3.3
Patch Yes

History
09/25/2009 02:00:30 PM Jan Schneider Comment #4
Assigned to Jan Schneider
State ⇒ Resolved
Milestone ⇒ 2.3.3
Reply to this comment
Fixed
09/25/2009 01:58:49 PM CVS Commit Comment #3 Reply to this comment
Changes have been made in CVS for this ticket:

Correctly check for ldap_get_entries() result (Bug #8595).
http://cvs.horde.org/diff.php/turba/lib/Driver/ldap.php?rt=horde&r1=1.54.4.22&r2=1.54.4.23&ty=u
09/22/2009 12:47:53 PM andydorman (at) comehome (dot) net Comment #2 Reply to this comment
Not sure of the correct patch format.  So I attached a simple diff to 
the original ticket.
09/22/2009 12:46:32 PM andydorman (at) comehome (dot) net Comment #1
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ 1-click add_address from message display fails with LDAP driver
Queue ⇒ Turba
Milestone ⇒
Patch ⇒ Yes
New Attachment: turba_lib_Driver_ldap_diff.txt Download
State ⇒ Unconfirmed
Reply to this comment
The bug was noticed with the latest stable Turba (just updated to 
2.3.2) & 2.4.17 OpenLDAP for address and address book storage.



I noticed last week that clicking on the little "add" icon next to a 
new address (ie, an address not yet in my default address book) in the 
IMP message display gave me an error "Read failed: (0) Success"



Clicking on "add" for an existing address returned the correct 
"Already exists" result.



I found the issue to be the method, _get_results, in 
turba/lib/Driver/ldap.php, that checks the results of a search for a 
duplicate address before adding the new one .  When nothing is found 
(ie, the results array is empty), _get_results (line 491) considered 
that to be a PEAR error.  However, lack of results only means a search 
came up empty, not that there was an LDAP error.  We should check the 
error code before declaring a problem.



The good news is that fixing it, for OpenLDAP anyway, is simple.   
OpenLDAP returns an error code of 0 when there were no LDAP problems.   
So it was a simple matter to add a check of the error code before 
declaring that there was a problem.


Saved Queries