The thing that is crazy to me is that I came from LastPass in 2020 (I think), and LastPass had options like this. So with Bitwarden being a competitor, it’s surprising they Don’t have features like this or haven’t implemented this yet.
It is a feature many users ask for - see this huge thread, has 774 votes, and this request is on top for many years.
Now I wonder which reasons prevent the developers to implement/add more pre-definded item types. I guess there must be reasons …
Update: there are no plans to introduce new item types currently. SSH keys were built as a new item type because it was also built with a SSH agent to allow for server authentication, signing Git commits, and interacting with SSH services on the desktop app.
Given the variety of item types, it is difficult to pick the exact right mix of item types for everyone that also doesn’t clutter the UI, especially when most users only store logins and no other item types.
@MFKDGAF that’s a helpful note about the expansion on custom fields, that could be a nice approach that provides flexibility for everyone. We do have the ability to add additional URIs on the login, is there something else you’re looking for?
I think that users who have expressed an interest in custom field of the URI type would like to do things like create a Card Item and include a URI to the associated online account, for example. Such a custom field should include a “launch” function.
Another use-case that I think would be of interest to many users would be custom fields to store dates (similar or identical to the expiration date field that is provided in Card Items); these might hold password expiration dates, expiration dates for software licenses, etc.
Custom fields with functionality similar to password fields (especially the ability to generate a random character string or phrase using a icon that is available in the field when edited) would be helpful for generating and storing answers to “secret questions”.
I miss the ability to save individual passwords, where you can also generate passwords directly from the saved passwords, as well as creating documents, software licenses, and bank accounts.
I don’t necessarily need the same item types from 1Password, but those would be the most important ones for me.
- Individual passwords with the ability to generate them
- Documents
- Software licenses
- Bank accounts (IBAN, BIC, Typ, Kontoinhaber, Name, Notizen)
Bad news for us …
What does this mean? How is it different from a file attachment, which is already possible in Bitwarden (for Premium subscriptions)?
Regarding this sentence, I’ve listed what I personally use/need. I’ve listed what doesn’t exist yet, as well as documents that are already available.
A shame. I thought that Bitwarden was on the right path lately, with a some big gaps closed, but then we have such essentials. I feel that my vault is unorganized because this is missing. Please implement this. Ideally I’d like to have a couple of basics pre-defined (software key, ID, WiFi, software key, etc) and then have to option to create our own templates as well.
@gtran: Your answers sounds little bit like “we do ignore the opinion of our users” and “we do not want to look at what our competitors offer”. I am sorry for these negative words. But these words came in mind when reading your answer.
I am sure there is no bigger discussion in the forums of 1Password/Enpass/… about the mix of item types. Users are happy to use (if needed) different item types. It would be very similar here, many users of Bitwarden would also use different item types. Of course, there will be a discussion and some will complain or ask for this or that, but as you can see: It is a feature many users ask for (and voted for, 774 at the moment), for this thread exists since 2018.
Btw., a question: How many users use the SSH item type? To me, this item type “clutters” the UI because I do not use it but I see it always in the “Types” section. But I can live with it.
I am not afraid of cluttering of the UI. There are always solutions for integrating new functions in a way which does not clutter the UI. You managed to add the item type SSH, so you also will manage to add other types, or ask someone who has experience in designing UI.
I also think it’s a real shame. I also think it’s a shame that the sorting suggestion is given priority over the item types.
@gtran This seems like an excuse. This makes it appear that Bitwarden simply doesn’t want to invest the time and effort to implement features that users have requested for years, which are already available in other password managers like 1Password, Enpass, and LastPass. Additionally, Proton Pass, another open-source password manager, already has additional item types on their roadmap.
A practical solution could be to have these additional items hidden under a submenu called “Additional Items.” This submenu would only appear when a user creates a non-main item type that is not a Login, Card, Identity, or Secure Note. The structure would look like this:
-
Login
-
Card
-
Identity
-
Secure Note
-
Additional Items
Items such as SSH Keys, Social Security numbers, IDs, and WiFi information, along with other user-requested items, can be stored in “Additional Items” and their menus/items will be populated once added.
The “Additional Items” menu would function similarly to the existing main categories (Login, Card, Identity, Secure Note). When a user creates an item that corresponds to a specific type, a corresponding menu will appear in “Additional Items.” For example, if a user creates a WiFi item, a submenu “WiFi” will appear in “Additional Items.” To be clicked or tapped to be taken to all WiFi Items that have been created. This menu will not be visible in “Additional Items” unless a user creates an item of that type for that menu.
In the “Create” menu, users can have an option labeled “More Items” to access other item types beyond the main four (Login, Card, Identity, Secure Note). Users will not see these additional item types in the “Create” menu unless they select “More Items.”
This approach ensures that the interface remains uncluttered, and users who do not use the additional items will not have to see them.
Problem solved!
Image below showing the main page of types that Bitwarden offers on the my vault page. “Additional items” could be added under those four types:
I have a different take on @gtran’s observation. This conversation has many different opinions of what item types should be added and which field names ought to be included in any given item type. Since these ideas are not coalescing into a common set, it becomes impossible to invest in a development effort that would satisfy most requestors without requiring ongoing tweaking by developers (e.g. add my credit card brand to the list).
In my mind, it is time to regroup. Today, one can create a secure note adding whatever custom fields you desire. This can be the basis of custom item types. For example, a Wifi item type can be simulated by creating a secure note named “WiFi Template”, stored in a folder named “WiFi” and with empty custom fields named “SSID” and “Password”. Then, when you visit the coffee shop, clone the template, fill in the relevant fields and save it. Ditto at the hospital and library. This works today.
What could Bitwarden do to help? Well, they could formalize this process with a Blog entry. Maybe they could create a “clone without data” menu item that allows any item to easily be used as a template. And maybe they could create an “export selected items” to make it easy to share templates with others.
One issue is that the existing custom field types (text, hidden, boolean, and linked) are not sufficient for manually creating all new item types. Certain types of fields should have associated functionality that cannot be achieved with existing custom field types. For example:
- For autofilling, certain input fields require numerical input, and will not accept text data that is autofilled from a custom field of the “text” type.
- Fields for storing URIs should, at a minimum, have an associated “Launch” function.
- Fields for storing password-like secrets should have an associated “Generate” function.
- Fields for storing TOTP keys should have the ability to generate (and autofill) TOTP codes.
- Text custom fields are currently limited to 5000 characters (after encryption), but fields that accommodate more information may be required for some applications.
- There may be a benefit of defining a field type to hold dates (which can be displayed using formatting conventions determined by device locale, and/or parsed into separate year/month/day values for autofilling purposes).
Ideally, any field type that already exists within any of the four available item types should also be made available as a custom field type (and offer the same or substantially similar) functionalities.
Unfortunately, it seems that in the past, moderators have merged any feature requests that propose new custom field types either into this thread or into the feature request for customizable vault item templates. In my opinion, a dedicated feature request topic should be made for additional custom field types. Yes, there could be scope creep with such a feature request, but I think that once a dozen (or even a half-dozen) of the most versatile custom field types have been implemented, the needs of 80–90% of users will have been satisfied.
Hopefully, @gtran’s recent request for input about new custom fields types will lead to some progress in this direction, which would ultimately reduce the need for expansion of the pre-defined items types (especially if they also develop a more streamlined approach for constructing and deploying customizable vault item templates).
@grb That would indeed be great, to have such additional fields with functions… and I like the idea of customizable vault item templates also… but second thought was: before millions of users create some common item types themselves then, with additional fields already there, it would make sense to have a pre-defined set of most common item types also.
Maybe I agree with @Terrance last post here then also somewhat - and I would phrase it like this: it’s not exactly rocket science to get to a set of the most common item types (IMHO, it neither has to be a comprehensive nor perfect set – the most common item types for a majority of all cases/usages would be “perfectly” fine, at least for me…). – Everything missing could be created individually with those various fields.
PS: But (thanks to @grb), I think I understood today, that missing field types is a much more fundamental problem than missing item types… (though probably also not rocket science to understand that…
)
Perhaps a survey with different item types would be useful. This would show which ones users want most.
The second comment in the customizable templates feature request proposes the ability to import & export customized templates — this would make possible crowdsourcing of new template development.
But as you’ve realized, the cornerstone to making any of this possible is greater flexibility in custom field types.