I have checked your behaviour on order and can confirm that this will be the reason if I add the > before searching. There is a difference in the search between: alpha charlie or >alpha charlie or >+alpha +charlie
alpha charlie → There are results for alpha* and charlie*, but there is no search order. I think they are mixed. > alpha charlie → I think this is your order as you described it. > +alpha +charlie → This is the filtered version…
I tested them all in the Windows client.
Since the default search has no sort or search order, it would be nice to fix this.
Search simply DOES NOT work as described. Like not at all.
Scoring doesn’t work at all. [someterm^20 otherterm] doesn’t make items with someterm fall at the top - in fact items without someterm at all are the top three items in my vault, before one with someterm shows up at all.
“+” doesn’t work as expected.
+someterm shows nothing, but I have probably ~100 vault items with someterm (in the name). (I also tried “+someterm”)
I dunno how it’s intended to work, but the desktop app doesn’t search ANYTHING like the docs claim. Not at all.
It’s possible I’m doing it wrong, but I’m not some green novice who doesn’t understand grep and other search stuff - and unless I’m really high on glue fumes, something really doesn’t work.
Ah, yes - the “>” does appear to fix things. [At least superficially - I need to do some more tests before I’m pretty sure that solves everything.]
I’d read the docs on searching - but it appeared that the > prepended a field filter. But it looks like any search that uses any of the lunr terms needs to be prefixed with “>”
So, at least, at first glance this does do the search and returns results more or less like I’d expect.
For example; “> +someterm +otherterm”
This returns only items that contain somterm AND otherterm - from most any field (not just name, but notes too)
The search actually works a lot like a Google search - it seems to put the AND results at the top, followed by the OR results. Anyone who is familiar with Google searches should find this intuitive, IMO.
Default search behavior should be complete Text, without any logic: We have a lot of shared passwords beginning with some prefix then a ‘-’ and then a id.
If I search now for “pre-system” (without quotes) I get all passwords, having this “pre” or “system”. I only want “pre-system”. Why do I need an OR logic? I only want one password for searching it. If I don’t know which was the correct name, I can search for a short password or search multiple times.
By the way: If I quote the search tearm, I get only this one. But only if it has a quote as prefix, not as suffix:
'pre-system ← good
‘pre-system’ ← bad
But here I need also to search multiple times: First time I get a lot of passes and then I need to search again. It is not efficient. Default search behavior should be the full text term, without any logic.
I agree, the current search is mostly useless. We have thousands of shared passwords in our organisation. With our old internal PW management tool, we had ANDed search terms and it took an average of 5-6 key strokes to narrow it down to 3 entries. 2 seconds, maybe 5.
With Bitwarden’s search? We’re lucky if users find a password in less than a minute.
Are you searching using the desktop app or browser extension? The Lunr search engine embedded in those clients is very powerful, so performing searches on multiple terms is certainly possible and fast. I think what most people are asking for in this thread is a more convenient way to limit search results without have to use Lunr search syntax.
I don’t feel like Lunr is in any way useful, even if we step away from our particular case.
Nobody knows its syntax: basic Google syntax would be the limit for most people, in my experience, and Lunr completely breaks when attempting to use that. You can’t expect random HR or marketing employees to learn a new query language they’ll never use outside of their password manager.
The default mode of ORing search terms leads to the opposite result of what users naively expect: They enter a word, they get too many results, they add another word to try and narrow down the results and they get more unrelated results. Only if they randomly happen to be on the web interface they might see the ? button next to the search bar and get to the Lunr description (native clients don’t even have that, the help is buried somewhere else), but see above problems with that.
It doesn’t seem to work anyway. I tried it a bit now, and the minus prefix seems to have a 50/50 chance of either working or making things worse by moving results with the excluded term to the top. Plus prefix does literally nothing. Why is this so opaque.
And in our specific case, we also have eight years of muscle memory to deal with, which certainly doesn’t help. But I’m fairly certain we’d have the same complaints if we went into Bitwarden from a clean slate. At the end of a day, a password manager is not a tool people should be consciously be engaging with, it has to be as friction free as possible so they can do their actual job.
Did the topic just get nuked? There was an open (if very long-winded to arrive at) question on whether or not the current default is “AND, then OR” or “just OR”. From what I can tell with the most recent desktop client (2022.6.2-2 as per AUR), it’s “just OR”.
If I type in my HOSTNAME, the first result to contain both strings is ranked 13th(!), while with our old password manager and its very rudimentary “AND all the terms” search it was first. If I specify it further to mysql HOSTNAME it… gets bumped down to spot 17. Order of the terms does not matter either.
To even find the full Lunr documentation to learn how to do such a basic query with Bitwarden, I need 4 clicks even if I know where it is (Help→Get Help→Search "search"→Click first result→Scroll aaaaaaaallllll the way down). If I then scroll through the entire Lunr documentation, at the very bottom I’m told to use +mysql +HOSTNAME to “simulate” AND.
It returns zero results.
So, to summarize
ANDing of terms is not done automatically by Bitwarden (or at least not consistently in all clients, I didn’t feel like testing all of them).
Either the Lunr documentation or Bitwarden’s implementation of it is broken, so we couldn’t do it manually even if we wanted to.
I still maintain that Lunr is is the wrong tool for the job. At best it should be an “Advanced” search squirrelled away behind a toggle (and actually work as documented); the default should be a naive search with standard search engine syntax ("" to force returning ANDed results and nothing else). Throwing in ORd results under the ANDed ones would be acceptable, if prioritizing ANDed results actually worked (consistently).