Great to see the much improved search functionality in Bitwarden.
I have read the linked article for search options but I suspect a lot of users won’t and either won’t get the results they want or will think it’s not working properly when doing a partial search.
I would suggest that the search option defaults to a wildcard search, for example, if you enter “pass” in the search field, it actually searches for “pass*”. When I think of any software applications I use, they all produce a wildcard search result and this change would make Bitwarden behave much more like the “standard” and give people the results they expect.
Yes, but not other fields. Is there a reason that you don’t use wildcard on all fields?
We use notes extensively and are really pleased to have the enhanced search capabilities. Personally I’m not that bothered as I know how to perform a wildcard search on those fields but I do think it will confuse users, who mostly don’t read the documentation!
Personally, we are using a self-hosted server with only a few users so performance isn’t an issue but I can understand it could be significant for the public server.
Search is performed on the clients, the server has zero knowledge on what’s stored in your vault. So it all depends on the device you’re using, not how well your server performs or how many users exist
I can understand that for an app where you have a copy of the data on the device and do’t necessarily have an internet connection but I would be surprised if that were the case for the web vault. Otherwise you would have to download a copy of the data every time you did a search.
I’m not a programmer so I haven’t looked at the code. I am prepared to be completely wrong!
My coworkers would intuitively just type alpha livec to find the first one - live mail.2nd for the second or another admin@ for the 3rd one. To accomplish this, right now they would use a syntax like this:
If I’m not mistaken (@kspearrin ?), the web vault uses your browser’s local storage to store your data. It performs all operations in this storage, locally to your browser. Only encrypted data is transmitted back to the server for sync.
Hello ! Any way to search in the other way ? It’s absolutely destabilizing when you search for example “Doctor CityA” and all the entry for Doctor and CitiyA are displayed.
I would like to ask to set default search in exact match but I will ask How to make a exact match please?
Hmm - it doesn’t look like it. Take a look at the example scenario here…
Disclaimer: As mentioned in another post, we use a “naming scheme” to add certain tags to the title of each password entry. This includes the customers name and allows us (in theory) to quickly find all related entries associated to a certain customer (customerXYZ in the example below).
All data/entries for customerYZX
For easier understanding, here’s the available entries / passwords that we have in our database related to the customer in question - basically just to depict the structure of the customers password entries:
Now, the goal in this search scenario is to only list entries that also contains the beta keyword in the title (which shouldn’t be much of a problem, since their hostname contains “beta” and the hostname is a tag in our naming scheme). Based on alternative password managers, I would try the following search keywords to accomplish this:
Sorry for nagging about this, but is there any way to adapt a more intuitive way to search/filter results without using LunrJS’s syntax?
Our users keep complaining about this and in fact still stick to the old password manager (which actually is read-only nowadays for a migration to BW) because “they never find anything they actually looking for” in BW - I’m slowly running out of ideas to make it more palatable for them
I see. Since “customerXYZ” and “beta” are in two different words (delimited by space), they are searched as separate terms. The following should work though. Maybe we can adjust the default search to wildcard each search word like this.
