Tickets :: [#1317] Inconsistencies between datatree and LDAP when working on a Kolab backend

6.0.0-alpha14

6/24/25

Summary	Inconsistencies between datatree and LDAP when working on a Kolab backend
Queue	Kolab
Type	Bug
State	Resolved
Priority	2. Medium
Owners	stuart (at)
Requester	a.gungl (at) gmx (dot) de
Created	02/07/2005 (7442 days ago)
Due
Updated	11/20/2006 (6791 days ago)
Assigned	11/22/2005 (7154 days ago)
Resolved	11/20/2006 (6791 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	No

11/20/2006 02:21:25 PM	Jan Schneider	Comment #8 State ⇒ Resolved	Reply to this comment
Fixed with patches from ~~#4662~~.

02/08/2006 11:39:38 PM	Jan Schneider	Comment #7	Reply to this comment
OK, we need a _username_hook_frombackend() then, that is enabled by default with Kolab, that makes sure that we always use the user's mail attribute internally. I added an example hook to hooks.php.dist, but it is untested, and I have no idea if it does what it is supposed to do. Please test.

02/08/2006 04:28:20 PM	tokoe (at) kde (dot) org	Comment #6	Reply to this comment
Hi, with regard to the upcoming kolab 2.1 and multidomain support it would be better to use the email address for internal queries. Ciao, Tobias

12/27/2005 12:01:26 PM	Jan Schneider	Version ⇒ Queue ⇒ Kolab

12/05/2005 11:44:06 AM	vovan (at) planet (dot) nl	Comment #5	Reply to this comment
Understood. So we should always use either uid or mail internally, no matter which one the user uses for login. Which one makes more sense, especially looking ahead to multidomain support in Kolab 2.1? How will user names look like then? Unfortunatelly I don't have development version of Kolab installed, so can't say anything about that at the moment. Maybe later I'll have some time to install it. Hopefully somebody can post come comments....

12/05/2005 10:48:39 AM	Jan Schneider	Comment #4	Reply to this comment
Understood. So we should always use either uid or mail internally, no matter which one the user uses for login. Which one makes more sense, especially looking ahead to multidomain support in Kolab 2.1? How will user names look like then?

12/05/2005 09:16:03 AM	vovan (at) planet (dot) nl	Comment #3	Reply to this comment
Can you point to that LDAP ticket? And why do you think we should use "mail" as the internal user name instead of "uid"? Does this have any advantages regarding to Kolab? I think there is some kind on missunderstanding... Firstly, I have the same issue as described in the ticket (tested with both the latest Horde-stable and Horde-cvs). The problem appears only when "uid" isn't the same as "mail". So in this case Horde with Kolab backend works correctly _only_ if you login with your mail address, but not with uid! Of course, I don't think we should use mail instead of uid as internal user name. Would be the best if we can use both of them without problems.

11/22/2005 11:34:36 PM	Jan Schneider	Comment #2 State ⇒ Feedback Priority ⇒ 2. Medium	Reply to this comment
Can you point to that LDAP ticket? And why do you think we should use "mail" as the internal user name instead of "uid"? Does this have any advantages regarding to Kolab?

02/07/2005 02:49:39 PM	Chuck Hagenbuch	Summary ⇒ Inconsistencies between datatree and LDAP when working on a Kolab backend

02/07/2005 01:42:47 PM	Jan Schneider	Assigned to stuart State ⇒ Assigned

02/07/2005 01:36:20 PM	a (dot) gungl (at) gmx (dot) de	Comment #1 Priority ⇒ 3. High Type ⇒ Bug Summary ⇒ Inconsitences between datatree and LDAP when working on a Kolab backend Queue ⇒ Horde Framework Packages State ⇒ Unconfirmed	Reply to this comment
Horde allows to login via "mail" or "uid" attribute value in LDAP. This works fine.However, the queries in the datatree are done based on the login value of the user. If uid=mail, that doesn't matter, but having uid=name and mail=name@domain might let the datatree double the data for the same user. In my case there is the problemthat data for the user can't be retrieved when he logs in via uid, while everything works fine when using the mail value. There has been a related ticket some days ago, which was about reading and storing in LDAP. This _is_ solved. This ticket is about using the same approach in the datatree, i.e. use the value for the primary LDAP search attribute (Prefs/Prefs/kolab.php sets $params['uid'] = array('mail', 'uid'); to access the Kolab LDAP server) for the datatree access (in this example the value of "mail" and not of "uid").