I’ve been using Bitwarden on and off, keep coming back to check out the new features and improvements. This time, I almost coulnd’t find anything that would keep me from using and upgrading it…until…
This is about search terms once again. This time about the way they get handled in the seach box.
I have about 30 Google accounts stored and properly namedin my vault. When I enter “Google” in the search box, I get 30 results. So I naturally add the name of the user to it to narrow down the result.
Other than expected, the results for Google don’t get condensed to show only those that also combine with the user, which would be only one.
No, now I’ve got 40 results; 30 for Google and 10 for the user.
I did read the help page on search but found no way to change this behaviour.
Is it strange to expect this kind of behaviour?
I’m adding my vote for this. The search is doing an ‘OR’ for multiple terms, instead of an ‘AND’. For example, when I want to find my “CiT Bank” entry, I type in “CIT”, and get a dozen entries that happen to contain the letters “CIT” in the name. So I enter a space, and then “BANK”, but instead of narrowing the list, it just adds everything with “BANK” in it, making things worse.
It seems to me that an ‘OR’ search for an account is less useful than an ‘AND’ search. If others prefer the ‘OR’ search, then perhaps this can be a preference setting.
Agreed. I moved our company to Bitwarden, from LastPass, about a year ago and while it’s a generally much better fit for us, default search relevance is still a major bug bear.
@GeoDosch seems to be right that the default behaviour is using OR when the way that all of my colleagues expect it to behave is AND.
We have many Office 365 accounts and use “o365” in the name of these accounts for easy searching. We also use a 2-5 character client ID, so that if we were to combine the two things xyz o365, we should be presented with just Office 365 results related to that client. However, what we get is a list of ALL Office 365 results combined with ALL the results for that client, essentially xyz o365.
>+xyz +o365 gets the results that my colleagues and I would like 99% of the time when we search for xyz o365. I would love it if this was the default behaviour, or at the very least, there was a tick-box option to enable this as the default search behaviour.
Obviously I don’t want to get rid of the massive power and flexibility of Lunr search, I don’t want to have to type in >+ + all the time, multiple times an hour either.
I don’t know/understand enough of the code to figure it out but I’m still looking. Hoping someone else is willing to lend their eyes too. I think a few lines just need to be changed to make it work. I would test if I had a test environment.
this seems to be a “feature” of lunr.js (https://lunrjs.com/guides/searching.html) search functionality. as described at the bottom of the linked article a logical AND can be simulated by requiring each term to be included.
i just tested this out in the browser and extension search fields and using the correct bitwarden search syntax it works as described.
to logical AND a search (using OP example) “Google” and “username” input “>+Google +username” into the search field and you will get only the results that include both “Google” (not sure about letter-case) and “username” in any field of a vault item. further refinements can be achieved with the “[fieldname]:[value]” syntax.
fortunately, this is a relatively low-cost investment to get more precise results, since you are only adding three characters to the query that you were doing anyway it should not slow you down significantly. and you can replace some portion of the username—after you input the unique part—with and asterisk “*” to shortcut the last part of the username. so instead of “username” you could just put “us*” or whatever is enough to uniquely identify “username” from all the other usernames you have.
Am I the only one that thinks this is still bad UI/UX.
The standard practice is that when you enter two terms to search by, it should find both. In other words, logical AND is the default, generally universally accepted standard.
Shouldn’t BitWarden default to the way things are done pretty much every where else. Imagine if you used the search for this form and it used logical OR instead of logical AND – the results would not be helpful at all.
And you type “alpha charlie” in the search field – you would expert to just see the first one. Right now it will show both of them because it is ORing the search queries.
It is not obvious. The current search settings are not the universally accepted way you see on the internet. Imagine searching Google and it defaulting to OR for your search query – that would be absurd. So you google “Bitwarden password manager” and it yields a bunch of results that have to do with being a manager and nothing to do with Bitwarden or password.
It seems not strange to expect a default AND behavior in stead of the OR which it is currently. The Bitwarden documentation does not explicitly explain this, and maybe assumes that the majority of use cases is searching with only one term (which could be true).
On the other hand, the doc does link to the Lunr search documentation, which makes clear how Lunr searching works.
Maybe changing the default to AND behavior when not using “>”, is not only a coding hassle, but also makes falling back to Lunr’s OR when using “>” not much clearer.
However, a clarification in the documentation about “multiple search terms” working as OR could be helpfull.
@imthenachoman we are saying the same thing. The way to filter results is to match all criteria. Therefore, if your criteria are “Alpha” & “Charlie”, you should only see the 1 result (as per your example).
What the default behavior should be is an opinion for us, but a design choice for Bitwarden. For certain is that the Lunr search engine does not work that way. Personally i would be prefer a default AND as well. But i respect the choice for Lunr. It’s only a few characters extra to create an AND search as has been pointed out in this thread:
>+apple +tree (AND search)
To be fair, in this example the search terms are not automatically padded with “*” before and after the term, unlike the straight:
apple tree (expanded to *apple* *tree*, an even wider OR search)
This means if you want an AND search with partial terms, you have to use:
>+*ap* +*tr* (AND search, matches items containing apple AND tree)
@imthenachoman I am saying that it should be an “and” search. While I understand what @Jochem is saying about the function being built in already, I would prefer “and” being the default for search with “or” requiring additional characters.
I do not understand why that is Lunr’s default. I do see there is a way to change it’s default behavior. I’ll have to see if I can figure it out and change it in Bitwarden. Maybe I can figure out how to add it as a user configurable option.
Or maybe if enough folks vote then Bitwarden developers would change the default to AND.
Hello! I also voted for it, because the topic of search is a “problem” for pretty much all of our users. The more intuitive variant of AND search should be the standard search. There might be a way to set the default search behavior in the clients settings. However, as feedback from our users they wants the AND Search. An indication that this would be possible with the following syntax: >+part1 +part2 is unfortunately quickly forgotten again or perceived as unnecessarily aggravating. I hope that there will be an update on this soon, as this will significantly improve the clients! A good search should be one of the most important components of a software. Thanks, Roman
I think I can add something new to this discussion by calling attention to the order of items returned from your searches. Yes, searching for alpha charlie returns both alpha and charlie, but the entry alpha charlie will be first.
This is actually exactly what you’d expect to see in a search engine too. They’re more than willing to show you results that don’t contain everything in your search, it’ll just filter them so the most likely matches appear first.
Perhaps the issue here is the search bar is located under the filters section and so we expect that adding specificity will reduce hits.
I agree that my ideal use case is to filter items down rather than to search through them and return all possible matches. That’s just not what we have today and I’m hoping I can make things a little more usable to everyone here right now.