Current behaviour of the Addressbook Search filter is to add a * in front and behind the filtertext that has been entered by a user. This causes some filter strings to fail:
- "jan" becomes "*jan*" => OK
- "ja*on" becomes "*ja*on*" => OK
- "*jan" becomes "**jan*" => FAILS
- "jan*" becomes "*jan**" => FAILS
This can be confusing to users, because a * in the middle works as expected, but *'s at either end don't.
In what follows, I assume a user adds these *-signs to work as a wildcard. There are several ways to fix this.
1. scan the filter text for *-signs. If one is found, assume the user is advanced enough to understand about wildcards and that he will put them where required. So don't have luma add any *. If there's no *, assume a 'clueless' user, and add * before and after for his convenience.
The advantage of this method is to allow advanced users more precise filtering, namely typical LDAP constructs for "begins with" and "ends with" are possible.
The disadvantage is that the search behaviour might not seem very consistent to a novice user. A search string without any * may give completely different results from a result that does contain a *.
2. only add a * to any side of the filtertext that doesn't have one yet. So "*jan" would be replaced with "*jan*".
This behaviour shows very consistent search results, but the "begins with" and "ends with" constructs are no longer possible. This option is the most friendly to novice users.
3. The second option could be improved by allowing the user to configure the filter behaviour with an option. This is what gq does for example. We could add a combobox next to or below filter text to have the user choose whether the filter should act as "begins with", "ends with", "exact match", "contains", or "none". The entry browser should then modify the filter text to ensure that this setting is assured.
- if the user choses "begins with", luma should ensure the final filter text has got only one * at the end.
- when the preferred setting is "contains", the filter text should be modified to have one star before and after.
- "None" would mean no modificatons to whatever filter text is entered. This would allow an advanced user to define the filter behaviour by himself by adding a * wherever he likes.
The advantage of this solution is flexibility. Any user can choose whatever behaviour he prefers, and even change it between searches. Disadvantage is that the gui gets another combobox, which may clutter it.
I am not sure which option would be best suited to fix this. All options have their pros and their cons. As a short-term solution, I have created a patch to implement the second option: add a * only when one is missing.