Field Limitations

GoodBits

I'm still getting to know 1Password. From what I can tell there are some limitations around adding fields to a card. Hoping I'm wrong but please let me know. Here is what I'm observing:

1. When a website requires more than a user ID and password to login (for instance site code, membership number, or pin), when 1Password auto-creates the record, it does not automatically accommodate creation of that 3rd field.
2. On identities, a user can only have one recorded address and cannot capture an address for future auto population such as a work address, mailing and shipping address, etc.
3. There's no way to change the default card structure. For instance, for many sites, the login only captures a pin and user ID or an email and password. I'd like to have a place to capture for ALL logins the email address and user ID, even if they are not used for logging in. Possible without creating that field for each and every record?
4. No way to get a card to default to hiding information that I don't care to see so that I can have a cleaner view of the cards. For instance, I don't really need to see the website, creation date or password strength. Can they be hidden by default?

Stephen_C

1. The way to achieve what you want is to re-create and save the relevant login manually. The linked page includes this:

Saving a new Login manually can be helpful for fixing Logins that are problematic or that were once working but have since stopped. It allows 1Password to refresh everything it “knows” about the page and start from a clean slate.

That's why the procedure helps in cases like that.

2. The way I deal with situations like that is to create separate identities for each of the relevant functions (home and work, for example).
3. I don't think that is currently possible on any automated basis.
4. No, sorry, that can't be done currently.

Stephen

GoodBits

Thanks. All of the replies to my recent questions were answered quickly and thoroughly. My only disappointment is regarding #2 above. In database design terms, the limitation and therefore necessary solution compromises what is called referential integrity and would unnormalized the data. I hope that AgileBits will find a way to allow each card and/or card type, to have associated with it n added fields, but especially for the Identity card type to allow incremental addresses/address types and phone numbers/phone types.

littlebobbytables

Hi @GoodBits‌

We have a feature request for this so I'm adding your voice to it too.

ref: OPM-1201