GNOME Bugzilla – Bug 304029
Highly Ineffective LDAP filters
Last modified: 2013-09-10 14:04:09 UTC
This bug has been opened here: https://bugzilla.ubuntu.com/10629 "The LDAP search filters generated by evolution to search for addresses in the directory are "highly ineffective" at finding people. Here is an example of looking for a person named Kelly Smith (cn: Kelly E Smith). # from our logs # lets find everyone named exactly kelly smith.*, of course the person is named Kelly E Smith, but I don't know his middle initial # in this case the user is not found, and I become so frustrated that I do the search using the command line ldap tool May 11 08:51:37 peregrine slapd[15549]: conn=298480 op=41 SRCH base="o=CSUN" scope=2 deref=0 filter="(&(objectClass=person)(|(sn=kelly smith*)(|(cn=kelly smith*)(sn=kelly smith*))(mail=kelly smith*)(displayName=kelly smith*)))" # here is an example of thunderbird doing a similar search for a user named Caleb Fahey (cn: Caleb N Fahey) # in this case the user is found on the first try, evolution would not have found this user unless I had known his middle initial. May 11 09:19:02 peregrine slapd[15549]: conn=300736 op=1 SRCH base="o=csun" scope=2 deref=0 filter="(|(cn=caleb*fa*)(mail=caleb*fa*)(sn=caleb*fa*))" In order to interoperate with organizations which store middle initials in the cn, it is suggested that the "any" component of the substring filter (as documented in rfc2251) be set to the last token in either the search field or the autocomplete feild."
Created attachment 88380 [details] [review] proposed patch for evolution-data-server
Please try this patch. I'm not sure if it will work fine with whole evolution, this patch only changes ldap search string generation, where are added stars in place of the first space (of consecutive spaces) between words. So the search string may be now same as from Thunderbird. Because it changes only first space in a space-sequence, then one could easily use spaces in filters and filter on more words. (I mean, put string "Mil C" will create ldap search value "Mil* C*" (for 'starts with'), so ldap will search for two words separated by a space.) As I tested this, then if you have cn like "Milan Crha" and you will search for 'starts with' "Mil Cr", then resulting filter value in ldap will be "Mil*Cr*", which _will_ return correct result in ldap, but this name isn't displayed in Evolution (it's filtered somewhere else, not in ldap).
I did look there, and it needs to change in evolution-data-server/addressbook/libedtata-book/e-book-backend-sexp.c those helper functions for comparing strings thus they will work with spaces in same way like in the patch from comment #1. Because this is such a big work, it will need an approval from evolution developer(s).
I think the correct way to solve this would be: 1) when a full_name contains search is done, add wildcards between each word. 2) Change Evolution so that the default contact search is "fullname contains" not "fullname startswith", which isn't really that intuitive when middle names are stored in the addressbook.
ad 2) Maybe we need to change that same thing when autocompleting email address when composing new mail, what do you think Ross?
Created attachment 88608 [details] [review] evolution part of proposed patch for evolution; only changes description and filter string of default filter "Name begins with" on "Name contains". Because of that description change, it may need to translate properly (but I'm not sure with this.)
Created attachment 88609 [details] [review] e-d-s part of proposed patch for evolution-data-server; it's a bit longer, I added a few helper functions there, but I hope it will be fine. It only separate filter string into words and then recursively searches for these words, instead of searching for all words like it is one. I also improved an endswith function, so it works well with prefixes. (I mean, with name "Ross", when you will look for endswith "s" then old search will not work properly, this one will).
Ross, can you review it for 2.11.3?
Ross: poke
Ross: for 2.11.90?
Comment on attachment 88609 [details] [review] e-d-s part of proposed patch endswith_helper() in -sexp.c is very slow and should be able to be rewritten as a string comparison, something like e_util_utf8_strstrcase (s1 + strlen (s1) - strlen (s2), s2).
Created attachment 94539 [details] [review] proposed eds patch for evolution-data-server; you've right, ross, here is an improved patch. God knows why I did it such complicated...
ping ross, can you review this, please?
ross: ping.
Ross, ping again, this took awfully long time, and it's not so hard, can you review please?
Hmm. Well, I'm not entirely convinced that this is the best solution, but it should work.
eds part committed to trunk. Committed revision 8979. evo part committed to trunk. Committed revision 35635.