Bug 110867 - Search/Find button for LDAP lookups in composer
Summary: Search/Find button for LDAP lookups in composer
Status: RESOLVED WAITINGFORINFO
Alias: None
Product: kmail
Classification: Applications
Component: keys and menus (show other bugs)
Version: 1.8.2
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-16 10:12 UTC by Anton G. Alvedro
Modified: 2012-08-19 00:39 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Log and diff (5.27 KB, text/plain)
2007-02-16 08:40 UTC, Marco Walther
Details
ldapSearch.patch (2.09 KB, patch)
2007-02-17 17:25 UTC, Christian Schaarschmidt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Anton G. Alvedro 2005-08-16 10:12:59 UTC
Version:           1.8.2 (using KDE 3.4.2, Kubuntu Package 4:3.4.2-0ubuntu0hoary2 )
Compiler:          gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2)
OS:                Linux (i686) release 2.6.11.12

It would be useful to have a button to command LDAP lookups in the composer, maybe with a progress bar anywhere.

Although the autocompletion feature works fine, it is can be slow on big corporate databases. The result of this is that you never know if the engine is still searching for the guy, or if it was not found.

Anton
Comment 1 andrewb 2006-02-21 00:49:33 UTC
Further to this, the current behaviour of searching in LDAP to try to autocomplete everything you type into an address field in the composer is really broken... it generates a lot of network traffic, especially in the beginning when you have typed something like "A" and it does big searches on the directory. It also noticeably blocks / slows down the composer UI, and chews CPU processing and rendering the big list of autocompletion results. I would consider it a bug.
Comment 2 Marco Walther 2007-02-09 21:19:29 UTC
For me the input in the address fields does not show up until the LDAP search is over (around 3 minutes 100% CPU on a centrino duo). That's with a large LDAP directory (35,000 people ++) and KDE 3.5.6/KMail 1.9.6.

Some problems:
* There is no feedback what you typed
* There is no way to stop the search
* Overall the search is way to slow. When I type multiple addresses, I get to enjoy the wait as many times:-(

Comment 3 Marco Walther 2007-02-16 08:38:43 UTC
I think I found the reason for my problem:-( The 'keyword' handling in AddresseeLineEdit/KMailCompletion :-( I'll attach a little log which shows that
AddresseeLineEdit::loadContacts() takes 292 seconds to add my 46000 entries.

With a little change to disable the keyword inclusion, the same 46000 entries are added in about SEVEN seconds. I like that a lot better;-)

I don't have an idea how to fix that yet, but I'll think about it.
Comment 4 Marco Walther 2007-02-16 08:40:01 UTC
Created attachment 19701 [details]
Log and diff
Comment 5 Christian Schaarschmidt 2007-02-17 00:23:39 UTC
is your LDAP enabled in KAddressbook?
Please remove the checkmark from your LDAP-Addressbook, apply this patch and let  me know the results (with keywords enabled ;-)

--- addresseelineedit.cpp       (revision 630959)
+++ addresseelineedit.cpp       (working copy)
@@ -99,6 +99,7 @@ AddresseeLineEdit::AddresseeLineEdit( QW
   m_completionInitialized = false;
   m_smartPaste = false;
   m_addressBookConnected = false;
+  m_searchExtended = false;

Comment 6 Marco Walther 2007-02-17 01:14:44 UTC
On Friday 16 February 2007 15:23, you wrote:
[bugs.kde.org quoted mail]

Yes, but I only use a local cache. There is no network traffic involved.

Ja, aber nur ein lokaler Cache. Es ist kein Netz beteiligt. 


> Please remove the checkmark from your LDAP-Addressbook, apply this patch


Without my LDAP cache, I don't have any addresses more. So the completion 
vector will be VERY small;-)

Wenn ich mein LDAP-Cache ausschalte, hab' ich keine Adressen mehr;-)  Das 
hilft natuerlich;-)


> and let  me know the results (with keywords enabled ;-)


I don't think that disabling m_searchExtended will help me at all. My problem 
is really the loadContacts() which takes almost five minutes to complete. But 
in that code, m_searchExtended isn't checked at all. When I disable the 
keyword MAP handling, the same setup only needs seven seconds;-)

Ich glaub' nicht, dass der patch bei meinem Problem helfen wird. 
loadContacts() braucht wirklich fast FUENF Minuten bis es alle Adressen in 
die diveresen Map's verarbeitet hat.  Und dafuer spielt m_searchExtended 
ueberhaupt keine Rolle:-(  Ohne die keyword MAP, sind es noch ganze SIEBEN 
Sekunden. 

Have fun
Viel Spass noch;-)
-- Marco


>
> --- addresseelineedit.cpp       (revision 630959)
> +++ addresseelineedit.cpp       (working copy)
>  @ -99,6 +99,7  @ AddresseeLineEdit::AddresseeLineEdit( QW
>    m_completionInitialized = false;
>    m_smartPaste = false;
>    m_addressBookConnected = false;
> +  m_searchExtended = false;

Comment 7 Christian Schaarschmidt 2007-02-17 17:25:31 UTC
Created attachment 19720 [details]
ldapSearch.patch

I have created a local LDAP with 100.000 entries and it takes less than 10
seconds to load, I have no explanation for what you have measured. Nevertheless
there are some issues that need to be fixed (see patch):
- ldapSearch was broken
- ldapSearch did not search for domain
- loadContacts did load *all* contacts for all resources, this should not
happen for ldapkio, we have a asynch. ldapSearch. (BTW, this is not acceptable
for corporate environments, we need to	look into it for KDE4/akonadi)
- there is no reason to reload local addresses with each ldapSearch
- cache ldap-entries. ok, it will require to restart kmail to refresh cashed
ldap-entries, but how often will that happen?

I would appreciate some feedback on the patch before I commit, thanks!
Comment 8 Christian Schaarschmidt 2007-02-23 20:53:01 UTC
SVN commit 636670 by schaarsc:

- fix broken ldapSearch
- lookup domain in ldapSearch (kmailcompletion already does)
- do not load all contacts from ldapkio, use ldapSearch instead
- do not reload local contacts  with each ldapSearch (implies contact caching)
CCBUG: 110867


 M  +6 -4      branches/work/kdepim-3.5.5+/libkdepim/addresseelineedit.cpp  
 M  +2 -2      branches/work/kdepim-3.5.5+/libkdepim/ldapclient.cpp  


--- branches/work/kdepim-3.5.5+/libkdepim/addresseelineedit.cpp #636669:636670
@@ -99,6 +99,7 @@
   m_completionInitialized = false;
   m_smartPaste = false;
   m_addressBookConnected = false;
+  m_searchExtended = false;
 
   init();
 
@@ -524,8 +525,9 @@
       int weight = config.readNumEntry( resource->identifier(), 60 );
       s_completionSources->append( resource->resourceName() );
       KABC::Resource::Iterator it;
-      for ( it = resource->begin(); it != resource->end(); ++it )
-        addContact( *it, weight, s_completionSources->size()-1 );
+      if ( resource->type() != "ldapkio" )
+        for ( it = resource->begin(); it != resource->end(); ++it )
+          addContact( *it, weight, s_completionSources->size()-1 );
     }
   }
 
@@ -633,7 +635,7 @@
 
     keyWords.append( email );
 
-    /* KMailCompletion does not have knowlege about identities, it stores emails and
+    /* KMailCompletion does not have knowledge about identities, it stores emails and
      * keywords for each email. KMailCompletion::allMatches does a lookup on the
      * keywords and returns an ordered list of emails. In order to get the preferred
      * email before others for each identity we use this little trick.
@@ -744,7 +746,7 @@
   if ( s.isEmpty() )
     return;
 
-  loadContacts(); // TODO reuse these?
+  //loadContacts(); // TODO reuse these?
   s_LDAPSearch->startSearch( s );
 }
 
--- branches/work/kdepim-3.5.5+/libkdepim/ldapclient.cpp #636669:636670
@@ -427,8 +427,8 @@
    * This allows both resource accounts with an email address which are not a person and
    * person entries without an email address to show up, while still not showing things
    * like structural entries in the ldap tree. */
-  QString filter = QString( "&(|(objectclass=person)(objectclass=groupOfNames)(mail=*))(|(cn=%1*)(mail=%2*)(givenName=%3*)(sn=%4*))" )
-      .arg( mSearchText ).arg( mSearchText ).arg( mSearchText ).arg( mSearchText );
+  QString filter = QString( "&(|(objectclass=person)(objectclass=groupOfNames)(mail=*))(|(cn=%1*)(mail=%2*)(mail=*@%3*)(givenName=%4*)(sn=%5*))" )
+      .arg( mSearchText ).arg( mSearchText ).arg( mSearchText ).arg( mSearchText ).arg( mSearchText );
 
   QValueList< LdapClient* >::Iterator it;
   for ( it = mClients.begin(); it != mClients.end(); ++it ) {
Comment 9 Christian Schaarschmidt 2007-03-28 22:25:58 UTC
patch committed to branch/3.5 rev.647591. makes sure ldapSearch is used, will reduce CPU usage
not closing, because request was for progress bar.
Comment 10 Myriam Schweingruber 2012-08-18 07:52:38 UTC
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented.
Thank you for your understanding.
Comment 11 Luigi Toscano 2012-08-19 00:39:32 UTC
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.