Not all contacts appear in search

[albertvisuals]

I have setup a CardDAV adressbook with about 4867 adressbook entries. Strangley not all adressbook entires appear in Roundcube. The changes of the entries of the adressbook appear in the original adressbook tough...
What could this problem be?

[albertvisuals]

It seems that it has something to do with the selection in which fields it should search. When I select all fields the contact does not show up, when I de-select "all fields" it shows up.. Strange

[mstilkerich]

Hello,

can you please elaborate a bit more on the issue:

• Do all contacts show up in roundcube in the addressbook listing? (Not using the search function)
• For a contact that does not turn up in the search function, can you give an example what you enter in the search field, and what part of the contact information should match?
• Ideally, please provide the VCard for that example contact. You can get it from the database (carddav_contacts table, vcard column).

[albertvisuals]

Hello Thanks for the fast answer!
Yes all the contacts show up in the listing. It has somewhat do to with the search feature of Roundcube.
When I search with the Lastname or Firstname or some letters of the name the "right" contact does not show up, unless I de-select "all fields" form the search dropdown - then the contact show up.
I firstly thought not all contact have been synced, but this is not the case. Maybe there is a bug in the search function of the last roundcube relase?

I sadly cannot share the vCard due to EU GDPR. But it was just first- & lastname, E-Mail address, telephone and some lines in the notes filled out.

[mstilkerich]

Well a dummy vcard that shows the problem would be fine for me, too. Or you could alter the strings.

When you flick the all search fields switch, the stored VCard will be searched. For the other attributes (firstname, surname, name, email), there are dedicated DB columns so in case all fields is deselected these columns will be searched instead of matching the entire vcard. With "all fields", it basically does not matter where inside the VCard the search string occurs, it can even be outside the payload data.

So essentially when searching with "all fields" enabled for the string "stil" you would get a WHERE clause like: ("vcard" ILIKE '%stil%'), whereas when disabling this setting but leaving all the other search fields enabled, you would get "name" ILIKE '%stil%' OR "firstname" ILIKE '%stil%' OR "surname" ILIKE '%stil%' OR "email" ILIKE '%stil%'. The all fields filter is less precise and may return spurious matches because it matches against the entire VCard, not just its payload data. For example, when you search for BEGIN with "all fields" enabled, you would get all contacts because BEGIN appears inside every VCard.

Unfortunately, I cannot reproduce the issue on my end, it seems to work as expected. I tried this with postgres.

• Which DB are you using?
• Just to be sure - you are using the latest release 4.0.4 or a git version from the master or 4.1 branch?

[albertvisuals]

Thanks again for your answer!
I use MySQL 5.7.28 and Roundcube 1.4.10 + CardDAV V4.0.4
I have attached a dummy v-card.
Webmail - ALL-INKL.COM Kontakte.vcf.zip

When I search with all fields selected:
Search-Term: "Moti" => is not found
Search-Term: "TEST" => is not found

When I deselect all fields (searching: showed name, first-name, last-name, E-Mail)
Search-Term: "Moti" => is found
Search-Term: "TEST" => is found

Later: I have tried to insert "Moti" into the notes field => Search all fields selected => Search term "Moti" => is not found.

That's really strange as it should return the elements if all the v-card fields are searched....

And I don't now if this helps: Should the search be case-sensitive?

[mstilkerich]

Thanks, I can reproduce. It's because the search pattern is lower-cased, and the search which should be case insensitive is not. It's one of the old parts of the code that does not use the database abstraction but creates SQL statements directly. I recently changed to use of case sensitive collations in MySQL to have uniform behavior across the different DB locations, but forgot to update this part of the code.

This was broken with release 4.0.1.

[albertvisuals]

Glad that we have located the bug! Your plugin is really a great piece of work and makes Roundcube really worth it :) Thanks for your effort!

[mstilkerich]

Thanks, I'm happy you like the plugin. I have fixed this on the 4.1 branch, but it is quite a big refactoring because I now replaced all leftover direct SQL uses in the plugin; so chances are I broke something else. I want to create a couple of more test cases also for these topics before releasing 4.1, so this issue may still remain open for a while. But if you want you can try the 4.1 branch, which is done concerning features and only needs some more testing.