A less elegant work-around (but one that should work in mobile apps) would be to put the tag keywords at the end of the vault item’s name. If you don’t want to see the tags displayed when you list your vault contents, you could add padding characters until the tags are truncated.
For example, you could pad using non-breaking space characters (Alt+0160), as follows:
Amazon #Shopping #Personal
Staples #Shopping #Work
which would be displayed as:
Amazon ...
Staples ...
& nbsp;
Alternatively, you could pad with periods (.), as follows:
Perhaps instead of nonsense theoretizing you should work on some real open source yourself - I did for a while. This is just “open source” hidden behind a corpo and bunch of random corpo “standards” that result in highly requested features lingering for years until who knows when.
But “don’t cry” and “give them time” or maybe “just write it yourself”. Right. Remember that you are a customer sometimes (or maybe not, but many people are) and respect from customers can be easily gone and doesn’t last forever. Way bigger companies have gone bankrupt. Password managers market has luckily decent competition. Whiteknighting won’t help if the overall mood of the average customer drops to “I want to try something else because this is developing way too slowly or focusing on UI too much compared to other features”.
Your comment sounds very corpo as well (length >>>>> content, bunch of nothingburger phrases like “we must look at solutions to problems”) so I’m not surprised to see that opinion.
I’m not criticizing you personally, but your comment here. Sorry. But I do that, I contribute open source. I just don’t like to “promote myself”, I think it’s a waste of time.
I’m not criticizing you personally, but your comment here. Sorry, but I didn’t understand that part, could you be more specific?
I’m not criticizing you personally, but your comment here. Sorry. But no, you misunderstood what I said. I said that everyone has their reasons for not liking certain things. I said that some developers might get upset with bitwarden if they submit pull requests and they don’t get accepted. For example, there are cases publicly reported here of certain pull requests being ignored or with no response as to why they were rejected.
Likewise, there are “customers” who are upset because they wait too long for the roadmap or this feature to be completed. But the “Bitwarden team did not respond on this”. And because of that, they (the customers) have their reasons for not wanting to be a Bitwarden customer anymore.
In my case, I said that although both scenarios are possible, what remains is to create a separate open project, as such features were not accepted if you are a developer in this case. And if you are a customer and don’t like this wait, you can look for other alternatives such as Keepass, Endpass, Lastpass, 1password etc.
“In other words, solutions abound”. If developers are wary of Bitwarden, they could contribute to an open project or fork Bitwarden with the missing features. If you are a customer and not a developer, you could look for other alternatives to manage the password. So It’s no use getting upset if there are alternatives like those mentioned above.
In my case, I’m here more for “security” than “new features”, so I’m happy with Bitwarden the way it is. And I understand why people are upset about Bitwarden, although I see some general solutions to these general problems that may not be what most people want.
I’m not criticizing you personally, but your comment here. Sorry. But you have every right to be upset if you contribute open source and your pull-request request is ignored or not accepted, or if there is no response as to why. Likewise, if you are a customer of a company and you are waiting for one or more features to be developed and there is no response to this delay, you also have reason to be upset.
The difference between your view and mine is that I don’t complain when I can’t solve a problem. Or when I think that complaining is a waste of time, in addition to creating a toxic environment for people. And I’m not saying you’re toxic, but we should be careful with criticism and be specific about what we’re criticizing. Furthermore, being a customer or contributing to the code is not the real reason for the complaints, the real reason is the slowness of the development process in the sense of resource management, planning.
I just said that for some users this is not a big deal, if most people want security then everything had better be tested a lot before being released. For example, I’d rather wait than do something that I’m not sure is good for most people. I believe that Bitwarden is analyzing the good and bad scenarios about the features that we users want, that’s why the delay (this may or may not be it).
And I don’t have the answer to all the world’s problems.
For those tired of waiting who need a reliable tracking mechanism right now, a temporary workaround is to create an extra URI with the tag you want, then click the gear to enable the match mode dropdown menu, and set it to Never. Unlike notes and custom fields, the URI is actually indexed for searching, and setting to to never match prevents any possibility of a strange false positive autofill.
It’s not a perfect solution, and the UX certainly doesn’t stack up to a proper tag system, but for my use case it works. I absolutely needed a way to track which accounts had been secured with my Yubikeys for future reference in case a key is lost or damaged. This lets me do it without cluttering up the name portion.
As of now, this feature request is only 6 votes shy of 500. How about making this a feature-request issue on GitHub in the light of this demand?
It’s the 6th most upvoted feature request and (unlike other feature requests), the comments mostly agree that tags/labels are a lot more useful than folders.
Furthermore, the migration path from folders to tags/labels is pretty easy, even more so as Bitwarden folders don’t allow subfolders.
@sclark Ah, the Git way then. Thanks for the hint!
Not really a problem when converting to tags though, just give the user the choice whether to convert work/licences folders to [work/licenses] (one tag) or [work] and [licenses] (two tags).
Agreed. Your solution (providing a choice) would be ideal as I’d guess the user base would be split on how to treat subfolders. But even if Bitwarden made an executive decision (one or multiple tags), I’d gladly fix a bit of organization in the event they chose the way I would not have.
I have just finished importing my scrubbed data from Keychain. I am using a folder structure as a best effort at grouping though there are many instances where something overlaps a couple of the five folder areas I created. Sub-folders would add complexity without addressing the problem which is that some entries have major elements of A and B while others have B and C, or other aspects not covered by folders at all. For me, tags would be a good solution.
I’m new to Bitwarden and still going through the painful process of migrating from 1Password. I’ve encountered many problems importing over 1,200 1P items and more than 300 items with attachments (Bitwarden doesn’t support importing attachments). I prefer Bitwarden at this point, save for the migration process and (now) a lack of tagging. lol
My tags also didn’t import from 1Pass, which is a real bummer. I used them extensively–and folders just don’t cut it, especially when one item may have multiple contexts to which it applies.
Since there doesn’t seem to be an ETA for this feature (it seems to have been on the Roadmap for some time now), I found a simple workaround for now.
Tags can be added to the Notes field in a given item. There are a variety of ways to do this, but I chose the method below.
At the beginning of every Note for an item that I want to have tags, I add the following:
tag:tagname
I do this at the beginning so when I’m searching, I can easily see the list of tags for a given item when I viewing the search results.
It doesn’t seem that Bitwarden provides fuzzy searching. So in the search field, one would either have to type the full tagname, such as “tag:tagname” or one can use wildcards if unsure of the tag name, such as “tag:tag*”.
While a workaround, it’s pretty simple to implement and may be suitable (for now) to those who are yearning for the functionality.
If you ever need to search for tags in a mobile app, it is better to place your tags in a URI filed, as suggested here (because mobile apps do not include the Notes contents in searches).
Thanks for the hint!