Bug 74349 - ldap searches: searching by name should try both first and family name
Summary: ldap searches: searching by name should try both first and family name
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kab3
Classification: Miscellaneous
Component: general (show other bugs)
Version: unspecified
Platform: Debian stable Linux
: NOR wishlist
Target Milestone: ---
Assignee: Tobias Koenig
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-02-06 14:52 UTC by Marcin Kasperski
Modified: 2009-08-05 16:04 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcin Kasperski 2004-02-06 14:52:43 UTC
Version:            (using KDE KDE 3.2.0)
Installed from:    Debian stable Packages

In my ldap repository there is a person called John Smith (for example). Now I am using ldap search to find him and I enter 'Smith'. The effect: nothing is found. At the same time, evolution finds the person perfectly.

The reason? Wrong query!

evolution queries ldap server with:
    filter="(|(cn=Smith*)(sn=Smith*))"
so it founds the person whether the first or family name was given.

kaddressbook tries 
    filter="(cn=Smith*)"
and fails to find anything...

It is likely that the change as described above should be fairly simple to perform...
Comment 1 Tobias Koenig 2004-02-07 21:10:29 UTC
Subject: kdepim/kaddressbook

CVS commit by tokoe: 

Search for both attributes, cn and sn when 'Name' is selected as criterion.

CCMAIL:74349-done@bugs.kde.org


  M +1 -1      ldapsearchdialog.cpp   1.11


--- kdepim/kaddressbook/ldapsearchdialog.cpp  #1.10:1.11
@@ -285,5 +285,5 @@ QString LDAPSearchDialog::makeFilter( co
 
   if ( attr == i18n( "Name" ) ) {
-    result = result.arg( "cn" ).arg( query );
+    result = QString( "|(cn=%1*)(sn=%2*)" ).arg( query ).arg( query );
   } else if ( attr == i18n( "Email" ) ) {
     result = result.arg( "mail" ).arg( query );


Comment 2 Marcin Kasperski 2004-02-07 21:40:35 UTC
Will the fix above work for the autocompletion in kmail window too?
Comment 3 Tobias Koenig 2004-02-08 01:24:27 UTC
Subject: Re:  ldap searches: searching by name should try both first and family name

On Sat, Feb 07, 2004 at 08:40:38PM -0000, Marcin Kasperski wrote:
Hi Marcin,

> Will the fix above work for the autocompletion in kmail window too?
This should already work with KDE3.2

Ciao,
Tobias
Comment 4 mi+kde 2004-03-25 00:23:12 UTC
There are other fields out there, that can contain a name... For example, our LDAP server -- the MS Exchange -- stores full name in the field called ``displayName'', while the ``cn'' is just a four-letter abbreviation. There is also a field called ``givenName'', which, no surprise, contains the first name part of the ``displayName''.

I imagine, it would be difficult to chase all LDAP configurations possible, so kaddressbook should, probably, offer a way to choose, which fields will be queried for each possible query type (Name, Phone, Address, etc.) AND, which fields to request and how to map them into kaddressbook data.

A user should be able to browse the list of the known fields -- see ldapbrowser:

	http://www-unix.mcs.anl.gov/~gawor/ldap/index.html

That thing can even fetch the Base DN from the server -- very convenient...
Comment 5 mi+kde 2004-03-25 00:54:19 UTC
Actually, it looks like the rest of the schema is fine. So if kaddressbook can simply be modified to give preference to displayName _if available_, life will become much easier.
Comment 6 Marcin Kasperski 2004-03-26 18:07:24 UTC
displayName is defined for OpenLDAP too (schema inetorgperson) so using it too seems a good idea. So we could use the following query:

filter="(|(displayName=Smith*)(cn=Smith*)(sn=Smith*))"
Comment 7 Tobias Koenig 2009-08-05 16:04:24 UTC
The development of the old KAddressBook will be discontinued for KDE 4.4.
Since the new application has the same name, but a completly new code base we close all bug reports against the old version and ask the submitters to resend there reports against the new product.