Search: Combine search terms rathen than add them up

Search is maddening and seems to be getting worse. Search in January could find the whole phrase “2fa off” (without quotes) by using “2fa+off” (without quotes). Now the + is not working and some folks are saying it needs to be “>+2fa +off” (without quotes) but this returns records with “2fa” in one field and “off” in another field. How do I search for the exact phrase “2fa off”, so that it only returns “2fa” followed by a space followed by “off”?

Also search adds the “behind the scenes” leading and trailing wildcard asterisk in all fields except the Notes field.

I´m pretty dissapointed about search feaures. Like most users, we migrate from KeePass to BW and we need to use a lot of workarounds to improve search, permissions, etc. We have more or less 400 entries in our database. With Keepass you search for term with implicit wilcards and implicit AND but in keepass if you search for a term and add a second word in the query your result would have more item than search for one result. So if you need to search for name you are force to specify field. Also if you use custom fields you can search for the existence of the name field but not for his value (is ridiculous to me).
Is a very good tool for day to day operations but search is not user friendly and you finally run two or three queries to find what your looking for (or die manually searching through collections an items)

@rodriguin Welcome tot he forum!

Unless you are using a mobile app, the search will pick up both the name and the value of custom fields (although it does not use implicit wildcards when searching custom fields, so you need to search for the exact name or value, or add your own explicit wildcards).

But is an OR not AND. So you can´t refine your search based on a custom field. According to this Search your Vault | Bitwarden Help Center you can search for a fieldname with >fields:FieldName but no value. Also if you want to find an item with only two words (AND) you need to do >name:firstword +name:secondword. Is a waste of time.

I’m not arguing that the search interface can’t be improved but I want to set straight the record, as your posts contain some inaccuracies:

  • You can search for a custom field value using >fields:FieldValue, or just plain FieldValue.

  • The default search behavior does refine in the sense that a search for term1 term2 shows the items that contain both terms at the top of the search list, and only then shows results that include either term1 or term2.

  • You can refine a search based on a custom field value using >Term1 +fields:FieldValue or >+Term1 +fields:FieldValue (the latter excludes items that only contain FieldValue but not Term1, whereas the former demotes such items tot he bottom of the search list).

2 Likes

Agreed, bitwarden has a lot of good and flexible search capabilities. It does require some familiarization, perhaps not as intuitive as other search interfaces.

Change search so it use logical AND, so if I type pavel gmail it should filter all entries which have gmail and pavel in it. This is how trezor password manager works and it’s great but discontinued.

Thanks for the feedback! It will return those results, it just puts them at the top of the list and then shows additional search results after, like a search engine.

It does not put them to the top, they are mixed withing irrelevant results making search unusable.

I’m a developer. But I can’t agree with what Bitwarden do to their search function.
I wish it could be better, just a regular search without remembering any syntax would be the best.
But if anyone looking for a solution, try 1Password. It comes with a price, but it’s worth it.

I’m actually considering switching now. BW keeps making bad UI/UX decisions that make it difficult to use.

I just submitted another feature request for another BW issue. Let’s see if they decide to fix any of them.

I’m running into the same problem as everyone else in this thread - the search is uninuitive and too complicated. The expectation with search is that entering 2 words will start an AND search and putting quotes around a search phrase should do an exact match search for that phrase. We’ve been conditioned to expect this as this is how just about every other search feature across the internet works. Nobody wants to learn a whole new way of searching using operators for something that should be simple.

Also, searching for >+citibank +login only searches the entry’s Name field (i.e. if you’ve named the entry “Citibank Login” it’ll find it, but if you’ve named your entry “Bank Login” it won’t find it, even though “citibank” is in the URL). This is unintuitive as searching for just one word DOES search across all of the fields of the entries (i.e. searching for just “Citibank” will return entries with “citibank” in the URL). This is probably why some people are saying this type of search works and others say it doesn’t.

There are so many inconsistencies in how this search works that it just comes across as feeling really kludgy and unreliable.

@Cameron_Prockiw Welcome to the forum!

I suspect you may not like this response but I need to correct the record on the following statement in your comment:

Full-text searches will search all of the following fields: shortid , organizationid , name , subtitle , notes , fields , attachments , login.username , and login.uris.

The problem you experienced is because the advanced search (> prefix) does not automatically use wildcards at the start and end of each search term. Thus, to find citibank within the URL www.citibank.com, you would need to specify the search term as *citibank*. So your advanced search should have looked like this:

>+*citibank* +login

Thank you! That does work! Not to come across as ungrateful, but it really shouldn’t be this difficult. I’ve worked in web development for 25+ years and should have been able to figure this out on my own. I can guarantee that the rest of my staff will not go to this effort.

1 Like

My understanding of the issue is that to ensure cross-platform compatibility of the Bitwarden browser extensions and Desktop apps, they must use a search engine written in JavaScript and interoperable with Node.js. They have chosen to use the Lunr.js package, so most of the complaints about UX issues in Bitwraden’s search function should be directed at the Lunr devs, not Bitwarden.

That being said, there is no reason why the choice of search engine used by Bitwarden should not be revisited.

A post was split to a new topic: Complaints after trying Bitwarden for 1 hour

Very well articulated!