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.
Might be worth mentioning that this does not include results where there is no exact match (for example an item titled as [Alpha] [Charlie] Test access would not be listed here).
Instead you would need to add a beginnen and trailing asterisk to each search term:
> +*alpha* +*charlie*
This is quite cumbersome unfortunately if there are multiple search terms, especially for non tech-savvy clients. A way to apply this as the default behaviour would be highly appreciated.
Search simply DOES NOT work as described. Like not at all.
Version 1.27.1
Shell 11.4.5
Renderer 87.0.4280.141
Node 12.18.3
Architecture x64
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)
All that said, I’m kind of shocked that the default search isn’t an AND search as expected by nearly anyone using the tool. (As evidenced by all the posts upthread.)
I expect they’ll get a lot less grief if they change the search, BY DEFAULT, to an “AND” search.
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.
All except for the >
And as I re-read the posts up thread, I guess it should have been obvious - but it didn’t dawn on me till now that that wasn’t a “quoting” character it was part of the search.
So, I guess the part about the glue fumes might be more applicable after all.
I don’t know – I find it very unintuitive. If I enter two strings that should return nothing then I expect it to return nothing. But right now, since it uses OR, it returns results.
I find it very unintuitive. So does my wife who is not very technically savvy. I’ve tried to get my company to move to BW and this was one of the biggest issues folks had – that the search is bad.
I guess the question is, how can we get it changed?
@imthenachoman That sums it up nicely.
Whilst I (as an IT-guy) understand the reasoning behind the way its programmed, from a non-IT perspective it’s just not good.
I use my password plugin 50+ times a day - that thing need to be quick, simple and easy to use with shortcuts.
No matter what: that this issue keeps thousand of people from paying for this otherwise great software.
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).
