Contacts app && search for contacts by phone number

Hardware Librem 5
1

Today I was searching in my contacts for a landline number which called me on my landline phone during my vacation. The number was in this phone announced as +4989nnnnnnn. +49 is the international prefix of Germany and 89 the city where I’m located. I used the first few digits of the rest (6111) and could not get any match in the Contacts app. I investigate the reason for the failing match and it turned out, that it only gives a match when the number is stored as:

+4989 6111nnnn

i.e. ther must be a blank to separate city and number; if it is stored without a blank, to get the match when typing +49896111, i.e the search engine behind works on words and not of just patterns, like grep.

Is this by intention or a bug?

3 Likes
2

Sounds like a bug.

3

I would say “intention”. But whether it is desirable is arguable.

Possible workarounds:

  • export as any text file and use grep
  • use sqlite3
1 Like
4

I would search if a closed or open bug is already reported here. If not you could create one.

1 Like
5

I think the complications here are that it wants to do

  • a prefix match on the fly (as you type) and it wants to do it efficiently. That is probably more difficult to do if it may match anywhere in the string. That is probably impossible to do (efficiently) if allowing regular expressions.
  • matching against disparate data sources e.g. sure, against the sqlite database of local contacts but also against LDAP and other remote data sources (if any are configured), and that may then be limited by the capabilities of the data source to perform the search remotely.

Of course whether any of that matters depends on the scale of the problem i.e. how many contacts in total e.g. 10? 100? 1000? 10000?

1 Like
6

I think, it does not tries a prefix match. As I said the stored number was +49896111nnnn, i.e. without any blank. I did the search typing 6111 which gave on the fly three contacts, all of the where stored as +49 89 6111nnnn, i.e. with spaces between the international and local prefix and between the local prefix and the landline number. The number, I was looking for did not have had any space, and was not matched, not even when I tiped the remaining digits after 6111....

IMHO, numbers should always stored internally without spaces and matching should be done with regular expression on the full string, including the + sign and expanding the +sign also by digits following the international regulations, i.e. for Germany expanding +49 to 0049 and vice versa.

2 Likes
7

Sorry, I meant “prefix match on each word”.

1 Like