@Gabor_Hegedus Welcome to the forum! I moved your comment into a more relevant thread.
I am not able to vote, limits reached. My preference would be to have a “first char choose syntax” so for example
& alpha charl
may inclusive (and) search for alpha* charl*
Updated subject for increased clarity and to fix a typo.
was: Search: Combine search terms rathen than add them up
now: Search: “and” search terms together instead of “or”
I hope Bitwarden can appropriately learn from LastPass’s search function, so that when multiple words separated by spaces are entered in the search box, it can match items in the searchable parameters that include all of these words. For example, if there is an item with name “MicrosoftAccount” and username “testaccount@outlook.com”, it can be found by entering “Microsft test” in the search box both in the browser extension and mobile application.
I know that currently Bitwarden uses Lunr for its search function, but if the function I mentioned can be accomplished, it will be easier for basic users and for mobile application.
@jshir811 Welcome to the forum! I moved your post into an existing feature request on the same topic.
I would recommend that you read through the previous discussion, which also includes some work-arounds. For example, you can use advanced search techniques to find only items that contain all search terms:
>+term1 +term2
You can also include wildcards to match partial strings:
>+Micro* +test*
(please note that the > character is part of the search expression; it is required to access advanced search features).
I am aware that Bitwarden’s browser extension and web vault support wildcard searches, which is a powerful feature. However, on one hand, users often search their password vault not to perform more advanced deep searches but to find the specific password entry they need as quickly as possible. Therefore, if it could support the fuzzy search functionality I mentioned earlier—where users simply separate keywords with the space bar to quickly locate password entries containing all those keywords (in fact, most password managers besides Bitwarden already use this search logic)—I believe it would significantly improve users’ efficiency when searching for passwords.
On the other hand, the current Bitwarden Android and iOS apps only support the most basic search functionality, requiring users to enter continuous characters exactly as they appear in the password entry to find the correct match. This is highly inconvenient and makes locating specific password entries in Bitwarden’s mobile apps quite difficult.
I hope Bitwarden can appropriately learn from LastPass’s search function, enabling the search box to match items across all searchable parameters when multiple space-separated words are entered. For example, an entry with the name “MicrosoftAccount” and username “testaccount@outlook.com” could be found by typing “Microsft test” in the search box—both in the browser extension and mobile app. I know Bitwarden currently uses Lunr for its search functionality, but implementing this feature would greatly benefit basic users and enhance the mobile app experience.
Even though the Lunr search defaults to combining the search terms with OR, the search results are sorted so that items containing a larger number of search keywords are prioritized, appearing higher on the list. Here is the example that you described above — the desired account is second in the search results list:
However, when managing an extensive collection of password entries, the most precise match you’re seeking might not surface at the top of the results—it could be positioned significantly further down the list. The ranking methodology also appears counterintuitive. Taking the screenshot you provided as an example, why is the most relevant password entry only second in the ranking? The top-ranked item doesn’t seem to align more closely with your search criteria than the runner-up.
Furthermore, such search methods prove completely ineffective in Bitwarden’s Android and iOS applications. The search terms demonstrated in your screenshot, for instance, would yield no matching results on mobile platforms.
The first item is the top result, because the search term “test” appears more frequently (5×), compared to the second item, in which the search terms appear only twice. Lunr uses the Okapi BM25 scoring algorithm for sorting search results by relevance, as described here.
As a reminder, by adding a handful of extra characters to your search expression, you can get the exact behavior that you want (e.g., >+micro* +test*). But I do understand that the feature request here proposes that this should be the default search behavior, and that’s fine.
There is another feature request for this, which you may wish to support:
So this brings us back to the title of the question, which is the issue of “AND” versus “OR”. To answer this question, I believe we need to consider why users search for password entries in password managers. Most users likely have a clear purpose when searching within a password manager and would not input multiple space-separated strings without reason. The search logic of a password manager should prioritize retrieving password entries that match the most strings entered by the user, rather than entries with the highest frequency of a single string match.
I believe that the Okapi BM25 scoring algorithm is more suitable for search engine scenarios with massive results, where the goal is to retrieve the most widely relevant outcomes. However, it is not entirely appropriate for password vault scenarios, which have a limited number of entries and aim to quickly and precisely locate the corresponding entry. Therefore, I strongly hope to adjust the current logic to truly accommodate the usage habits of the majority of users.