[Tickets #2940] LDAP entry failes when cn contains comma

bugs@bugs.horde.org bugs at bugs.horde.org
Wed Oct 18 16:04:10 PDT 2006


DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://dev.horde.org/horde/whups/ticket/?id=2940
-----------------------------------------------------------------------
 Ticket             | 2940
 Updated By         | horde at dbservice.com
 Summary            | LDAP entry failes when cn contains comma
 Queue              | Turba
 Version            | HEAD
 Type               | Bug
 State              | Feedback
 Priority           | 1. Low
 Owners             | 
-----------------------------------------------------------------------


horde at dbservice.com (2006-10-18 16:04) wrote:

> if the name is edited, then CN has to change since that's the name
element. 
Yes.Typical CN is contatenation of firstname and lastname, but can be
anything. If you have two people with the same first/lastname in your
database, the CN ist the right place to make this entries unique. 

> And really the DN should be the primary key, not CN, right?
Yes, but the rest of DN after the first CN=... is constant. So I am always
speaking about 'relative primary key'. For example the entry for 'Doe,
John' in my LDAP has distinguished name (that's the case with comma in CN
attribute which I tested now): 

 cn=Doe\2C John,cn=robert,cn=private-addressbook,dc=mydomain,dc=com

but the part of DN  'cn=robert,cn=private-addressbook,dc=mydomain,dc=com'
is same for all my private addressbook entries.  

> Anyway, do you know where the space is diappearing?
No. Sorry, I am not PHP programmer and I do not understand horde
framework. Anyway I am sure it is not LDAP issue. I think it was something
changed in the handling of name, lastname and firstname attributes in the
last time. About one year ago there was possible to define 'name' as array
of first/lastname and put it into CN (see bug #2529). It was very good
enhancement, because 99% of CN=lastname+firstname. Another reason for this
enhancement is SyncML. Because there is nothing like CN in mobile/pda
contacts, this attribute is always mapped as 'lastname<space>firstname'
(should be configurable?). Here is snippet of my old map:

 'name' => array('fields' => array('lastname', 'firstname'),
                              'format' => '%s %s',
                              'attribute'=>'cn' ),

This does not work in the current CVS revision.  So I would start to
search here. 




More information about the bugs mailing list