https://bugs.freedesktop.org/show_bug.cgi?id=64177 Patrick Ohly <patrick.ohly(a)gmx.de&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Priority|medium |highest Assignee|syncevolution-issues@syncev |patrick.ohly(a)gmx.de |olution.org | --- Comment #1 from Patrick Ohly <patrick.ohly(a)gmx.de&gt; --- (In reply to comment #0) [...] Here's a proposal for extended searching. This supersedes the current specification in a way which keeps all old searches working: -------------------------------------------------- Searching ========= Supported searches: [ ] - An empty list matches all contacts. [ [ <search> ], [ 'limit', <number> ] ] - a 'limit' search term with a number as parameter (formatted as string) can be added at the top level term to truncate the search results after a certain number of contacts. Example: Search([['any-contains', 'Joe'], ['limit', '10']]) => return the first 10 Joes. As with any other search, the resulting view will be updated if contact data changes. The limit must not be changed in a RefineSearch(). A 'limit' term may (but doesn't have to) be given. If it is given, its value must match the value set when creating the search. This limitation simplifies the implementation and its testing. The limitation could be removed if there is sufficient demand. [ [ <search> ] ] - the same as [ <search> ] [ 'or', <search1>, <search2>, ... ] - combines 0 to n other searches and results in a match if any of the sub-searches matches. ['or'] without any sub-search does not match. [ 'and', <search1>, <search2>, ... ] - like 'or', but matches if and only if all of the sub-searches match. [ 'phone', '<number>' ] - Look up a valid phone number (= "caller ID"). The country code for the current locale is added if no country code was given in the number. Phone numbers in the unified address book must start with the resulting full number, after being normalized the same way. In other words: - Formatting does not matter. - Alpha characters are aliases for numbers on the keypad and match their corresponding number. - Additional digits in the address book are ignored, only the prefix must match (extensions may or may not be included in <number>). - Phone numbers in the address book which cannot be normalized cannot be matched. [ 'is|contains|begins_with|ends_with', '<field>', '<text>', '<flags>' ] - compares a specified field against the search text. For the 'is' operation, the entire field must match, for 'contains' anywhere inside the value, for 'begins_with' at the beginning and for 'ends_with' at the end. Fields are referenced as in the contact dictionary (see below), using multiple path components if necessary. Supported for matching are: 'full-name' - string 'nickname' - string 'structured-name/family' - string 'structured-name/given' - string 'structured-name/additional' - string 'phones/value' - telephone number 'emails/value' - string 'addresses/po-box' - string 'addresses/extension' - string 'addresses/street' - string 'addresses/locality' - string 'addresses/region' - string 'addresses/postal-code' - string 'addresses/country' - string The fields referencing value lists ('phones', 'email', 'address') check against any of the entries in these lists. Except for 'phones/value', all values are treated as text values. For text values, the default search without explicit flags is case-insensitive and accent-sensitive. Spaces between words matter. This behavior can be modified by giving additional, optional flags after the search value: 'case-insensitive' - force case-insensitive search (available for the sake of consistency and just in case, should the default ever change) 'case-sensitive' - force case-sensitive search For telephone numbers, only digits are compared. Latin alphabetic characters are treated as aliases for digits as they typically occur on a keypad or old rotary dial phones ('A', 'b', 'c' map to '1', etc.). If the full name was not set explicitly for a contact, the concatenation of the given, middle and family with a space as separator is used instead when matching against the 'full-name' field. Using the current syntax it is not possible to define searches where the *same* value must meet different criteria ("cell phone number containing the digits 1234"). Something like that could be added as a future extensions, for example by allowing search values to have more complex types than the simple '<text>'. term with a more complex type. [ 'any-contains', '<text>', <flags> ] - Sub-string search for <text> in the following contact values: first, middle or last name, formatted name, nick name, phone number, or email address. Optional flags include: 'case-insensitive' (the default), 'case-sensitive'. This search is equivalent to: [ 'or', [ 'contains', 'structured-name/given', '<text>', <flags> ], [ 'contains', 'structured-name/additional', '<text>', <flags> ], [ 'contains', 'structured-name/family', '<text>', <flags> ], [ 'contains', 'full-name', '<text>', <flags> ], [ 'contains', 'emails/value', '<text>', <flags> ], [ 'contains', 'phones/value', '<text>'] ] Note that lookup and search are different: the former is based on a valid number, the later on user input. A 'phone' lookup can compare normalized numbers including the country code, to ensure that the lookup is exact and does not mismatch numbers from different countries. Heuristics like suffix matching do not do this correctly in all cases. An 'any-contains' search is based on user input, which might contain just some digits in the middle of the phone number. The search ignores formatting in both input and address book. Compound searches with 'and' and 'or' are evaluated lazily, from the first to the last sub-search. Therefore it makes sense to list sub-searches that are more likely to match first. -------------------------------------------- -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=64177 --- Comment #3 from Patrick Ohly <patrick.ohly(a)gmx.de&gt; --- (In reply to comment #2) That query itself is fine and will be supported. It works as intended because there is only one structured-name. The comment is about value lists, like telephone numbers. For example, suppose you have two telephone numbers: TEL:1234 TEL:5678 Now you search ['and', ['contains', 'phones/value', '1'], -- You are receiving this mail because: You are on the CC list for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=64177 --- Comment #5 from Patrick Ohly <patrick.ohly(a)gmx.de&gt; --- This paragraph clearly needs more work: Using the current syntax it is not possible to define searches where the *same* value must meet different criteria ("cell phone number containing the digits 1234"). Something like that could be added as a future extensions, for example by allowing search values to have more complex types than the simple '<text>'. term with a more complex type. What I thought I had typed is: Using the current syntax it is not possible to define searches where the *same* value in a *value list* ... ^^^^^^^^^^^^^^^^^ "term with a more complex type." at the end needs to be removed. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=64177 --- Comment #7 from Patrick Ohly <patrick.ohly(a)gmx.de&gt; --- Field filters are also implemented and pass my tests, so I'll kick of a more complete test run and start packaging a snapshot tomorrow. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=64177 Patrick Ohly <patrick.ohly(a)gmx.de&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|PIM: more complex searching |PIM: more complex searching |and sorting |(done) and sorting (open) -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.