Combine Bank Account entry and Bank Logins

robfol

It would be VERY useful to have the Bank Account Records also able to function as the Login Pages

I have multiple accounts and each one also needs a login page, info has to be duplicated and cross-referred which leads to mistakes

EXACTLY same problem applies to Reward Programs and More

Anyone else?

---

1Password Version: 6.0.2b1
Extension Version: Not Provided
OS Version: 10.11.4b2
Sync Type: Dropbox

robfol

I see users have been asking for this since 2010!

Stephen_C

@robfol I have always taken the view that there's a difference between bank account logins and bank account details and am happy to save the two separately as a result. I don't duplicate information between the login item and the principal item and, if needed, simply link the two using a tag (although I don't normally find I even need to do that). I just treat a login as a login (with only the information necessary in order to login—perhaps including security questions and answers, for example) and all other information about the account goes in to the principal bank account item.

Although that felt strange at first I do now very much like the idea of having the relevant details separate.

Stephen

littlebobbytables

Hello @robfol,

I'm not sure we want to merge these. Of course we will make a note that of your interest and if enough people are asking it would be taken seriously but because of how vault categories have been designed it isn't a simple alteration. They are intended to hold very different information and while the information stored in a Bank Account item is almost never going to change a bank may change their digital site (although admittedly this is rare too) and force the requirement of creating a new Login item. I know for me that keeping them separate means I can have 3 Bank Account items that describe my three accounts at my bank and then the single Login item that enables access to all three is separate. Like Stephen_C I have no overlap of information as I use the Bank Account item to store all the bricks and mortar information while the Login item only stores the details required to log into that specific web site. May I ask, what information do you duplicate between these types of items and just in case it isn't obvious to me when I read the reply can you help me understand the value you gain by doing so? I hope it will help me better understand your viewpoint :smile:

generic

I would like to bump up @robfol 's suggestion. I do agree that you'd want to keep the current data model of having Bank info and Logins separate ... IF YOU WANT. that's going to map to many users needs, for sure. But allowing the option to tack on login info on a Bank info entry would also be useful (if that's your preference).

Thank you for considering it!

Drew_AG

Hi @generic,

Thank you for taking the time to write in with your feedback about that, we appreciate it!

But allowing the option to tack on login info on a Bank info entry would also be useful

Well, you'll be happy to know that's already possible! :) If you'd like to add website login details to your Bank Account item, you can do that by adding custom fields.

Keep in mind that Bank Account items can't be used to fill web forms, so if you want 1Password to be able to fill your username and password for you on your bank's website, you'll still need to have a separate Login item for that. If it helps, you can use Tags as a way to group two different items together in 1Password.

Thanks again for your feedback! If you need anything else, please let us know. Cheers! :)

generic

@Drew_AG thanks for writing back. I do know about custom fields (and do use them for my bank!) but as you had guessed, the reason I was asking for a login element to be combine-able with the Bank asset type, is precisely so I can get the benefits of autofill.

An alternative (that might only be relevant to me and my specific bank) would be to:

• Allow a structured (ie native, not custom field) URL to exist for the Bank asset type
• Allow the Bank asset type with the URL field defined to autosuggest like a Login asset type when the browser is displaying the Bank site. In that way, even if I might still have to copy/paste from my custom Login fields, the most painful part of it (three levels of selects and dropdowns to dig out my Bank info from the browser extension) is cut out from the effort.

Anyway, thank you so much again for considering this and for your quick return on my feedback.

Drew_AG

You're very welcome @generic, and thank you for your additional feedback & suggestions!

One thing I forgot to mention is that instead of using custom fields to add login details to your Bank Account item, you could add your bank account details to your Login item. That way you could still have all that information in one item, and 1Password would still be able to fill your username & password on the website. The drawback is that the item wouldn't be listed in the Bank Accounts category in 1Password, but that might not be a problem for you. You may have already considered that option, but I wanted to mention it just in case. :)

Again, we really appreciate hearing from you about this, and that you put so much thought into how you'd like to see this work. Knowing how our customers would like 1Password to work really helps us to improve the user experience!

generic

@Drew_AG Your suggestion (which is interesting) led me down a terrible rabbit hole:

1. The philosophical reason I would not be inclined to go the route you're suggesting is that I care about taxonomies and Bank is a more granular asset type than Logins (at least to me). But, well, philosophy is all well and good, and I like to be practical, so that wouldn't necessarily stop me from implementing your idea.

2. The main reason I would not be inclined to go with your suggestion would actually be* practical: I have* this set of saved queries that leverage some freeform attributes (or the absence of these freeform attributes) in individual entries' Note field. This allows me to quickly identify certain things of my entries. For example, I have attributes like 'HasPersonal', 'HasCC' (or NoPersonal, NoCC) to denote logins associated to sites where my personal information or my credit card have been offered at some point. Or I have another attribute of FixedUserLength[var] to denote these dumb sites that force you to use a shorter PW (and where I cannot, in fact, really secure the password as much as I want to.

These freeform attributes are* being leveraged in custom queries like "(!=RandomlyGenerated OR !=FixedUserLength and Asset Type = Login" allowing me to keep track of logins that either (In the case of this query) should really gain a Randomly generated password, or ... had incomplete notes!
You can see where this complicated approach was going: Because the Bank asset type is not a Login, or because the Credit Card asset type is not a Login, I could therefore write much more specific queries, and not get back a lot of noise where, say, no Credit Card asset should be returned for a query whose goal it was to tell me that a site Had personal information about me (this just doesn't apply to the Credit card asset type).
All this to say: there is a cost to messing with the taxonomy, at least in the way that I had layered my own Frankenstein data model on top of 1Password's, and the way I was exploiting it.

Now, and this is the part where your reply was a rabbit hole: the *** that appear above are really about the fact that upon your suggestion, I wanted to look at the way I had written my queries and see whether I could adapt them to be forgiving of futzing with the taxonomy in the way you suggested. And in seeking out my old queries i realized ... that queries were gone from 1Password6! And come to think of it, maybe they were even missing from 1Pass5 -- I probably hadn't looked at these queries in a while.

So now, I'm bummed because my (admittedly intricate) data model is no longer leverageable without these queries :(
I might therefore end up doing some of what you're suggesting -- since practical trumps item #1, and #2 is no longer a concern (sadly!!). But, boo...

generic

Wellllll... I should have googled this one first. The Smart folders are not gone. But i was looking at "all vaults" and didn't realize this would hide the Smart Folders which are vault-specific. So they are not gone. Exciting!!

But yeah, there's no way to make asset types multiselectable, so either queries are specific to one asset type (and not multiples) or they apply to all asset types (and this gets noisy). So i have to decide between your suggestion @Drew_AG and my saved queries.

OR ... At some point 1Password gains the feature suggested by the OP ;)

Drew_AG

Hi @generic,

Wow, thank you for sharing all that with us, it looks like you've come up with a bit of a complex system for yourself! That's definitely an interesting method. Sorry for any confusion about Smart Folders not showing up in the All Vaults view, but I'm glad you figured that out! :)

So, in your situation, it sounds like the best option is to keep two separate items: a Login item that stores the information used to sign into your bank's website, and a Bank Account item that stores details about your actual bank account. Fortunately that's also the easiest option, since that's how 1Password is designed. ;)

I previously mentioned using Tags as a way to group two different items together in 1Password. Something else I wanted to mention is that our new 1Password for Teams (and 1Password for Families) service includes a great new feature called "Related Items" that allows you to link items to each other. That would make it very easy to have two different items (i.e. Login and Bank Account) because you can link them to each other (the item details would have a link you can click on to instantly bring up the other item). I wanted to mention that in case that sounds like a useful feature for you.

Thanks again for taking the time to explain your specific use case to us, we appreciate it! Have a great weekend. :)