CiviCRM Community Forums (archive)

Full text search shows incomplete result sets when the number of results is high enough to kick in the pagination system. So, on large searches, there may be results hidden away that your users will have no way of seeing.

When there's enough results in a full text search that the paginations system needs to be used, it counts and shows only results from the particular search table (e.g. civicrm_contact, civicrm_address - not entity tables) that has the most results, ignoring all others.

To replicate on the demo:

• Do a full text search on something common- say, "s", on 'all' tables, and note the number of results. For me this was 111. It must be over 50 results else the pagination won't kick in and everything will just work
  
• Create a new contact with no matches in the most common 'table' from the search- so this would be no 's's in name or nickname (civicrm_contact). Say, "Mr Clean Name"
  
• Give them a matching attribute in a field stored on a different table- say, setting 'city' in 'main address' (civicrm_address) to "St Albans"
  
• Repeat the full text search. The total number will remain unchanged, and the new contact won't appear. Looking through the results, you'll notice they all have the match in the same full text search table (in this case, they'll all have an 's' in their name)
  
• Run a more specific search incorporating your broad search and also matching your created contact's other attribute to get less than 50 results and observe the difference. e.g. searching "ns" gave me 9 results, including my new contact 'Mr Clean Name', and also including several others with no 's' in their names but an 'ns' in their email, notes, address, etc who should have appeared in the original search but didn't.
  

Conclusion - when the pagination is used, it uses an incomplete result set consisting of only matches in the internal table with the most hits.

A clue? Here's one more way to trip the pagination up which will be interesting to anyone trying to fix this: find a results set where the grand total for an entity type exceeds the limit for one page, but where no one table exceeds the limit on its own.

For example at the time of testing, full text search on the demo found 48 results with 'b's in their names (so reported '48 contacts found'), and found many more with 'b's in their email, address or other fields on different tables for the contact entity type (probably around 70-80 or so). On showing all contacts, it gave the first 50 contacts found, including several contacts with no 'b' in their name but a 'b' in another field, and didn't show any pagination headers or footers.

So, it seems the SQL query has correctly limited itself to 50 results, but the pagination system thinks there's less than 50 results because it counts only the biggest table, so remains disabled and displays nothing. The results from row 51 upwards are inaccessible and the user will go away unaware of the many results they missed, thinking they've seen everything.[/list]