Why does 1Password for Mac not warn the user before converting attachments to documents?

Options
Ulmer4Liberty
Ulmer4Liberty
Community Member

Last year I went from being a very happy 1Password user to a moderately happy 1Password subscriptioner. This was the best way to extend 1Password protection to my family, and I'm happy that it's an option.

I'm not happy with some of the assumptions made by the developers that are, quite frankly, arrogant.

I decided to move ALL of my Software License records from my Primary Vault (local, synced with Dropbox) to a new vault synced with my 1Password family plan. Now, instead of neatly curated records that each contain several attachments (receipt email, license key email, anything I got from the vendor at the time of purchase), I have a giant pile of Documents with cryptic names along side my Software license records. After much searching, I now understand that Agile Bits thought this was a good idea and that it was intentional.

The fact that 1Password for Mac encouraged me to make an IRREVERSIBLE change to my database, that represents WEEKS of work to undo, without WARNING me is an utter failure of the user experience. It does not matter if the result was supposed to be better, the result is garbage.

There already existed tools for dealing with documents in 1Password. The fact that these particular documents were put into my database as attachments was specifically to encapsulate them with the records to which they belong.

So is there a way to clean this up?


1Password Version: 7.1.2
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

Comments

  • Ben
    Options

    Hi @Ulmer4Liberty

    I apologize for the frustration. Thanks for taking the time to share your use case with us, and the effects that the transition from attachments to documents had on your workflow. Indeed, as you say, this was an intentional choice made in an effort to make documents stored in 1Password more flexible. Not everyone wants to have to create another type of item (e.g. Secure Note, Software License, etc) in order to store a document. Additionally there are times where it makes sense to have the same document linked to multiple items, which is not something that was possible with the old attachments architecture. So, that is why documents in 1Password.com vaults behave the way they do. I understand that in some cases, such as the one you described, this creates an undesired effect. We have done some brainstorming on how we can achieve the best of both worlds. Unfortunately we haven't come up with anything solid yet. There is no "undo" with regards to this change. 1Password.com vaults don't support attachments, so if you're going to have documents in a 1Password.com vault they will appear as you've outlined.

    I wish I had more to share at the moment, but we do truly appreciate the feedback, and hopefully it'll help shape the way we handle documents going forward.

    Ben

  • Ulmer4Liberty
    Ulmer4Liberty
    Community Member
    Options

    I appreciate your time! I can also appreciate wanting to move the product forward, however respecting existing use cases ought to be pretty important... Also, at least the Mac version should really warn the user that they are about to break something (maybe only if some attachments exist at the time of the drag).

    Also, I don't want to give the impression that I don't respect the brainstorming you've done, but here is my $0.02 in case it sparks an idea:

    If the problem is that what you've got now is basically a bunch of tag-associations, then how about letting me hide documents with certain tags (or maybe an entire tag hierarchy) in the interface... and then making an "attachment" tag. If I try to make an attachment in the old fashioned way, it adds the "connect the document to my item" tag and an "attachment" tag automatically -- or maybe they just share an attachment-number-XYZAB tag... This is basically just using the tag engine to re-implement the old storage model.

    You would then have to pay special attention to items linked by the attachment tag hierarchy for certain operations (say moving an item), but you may already have to do that anyway. I'm not sure. In any case, this would invest in and move forward the tagging model, rather than re-implementing an older train of thought.

    They may already be possible, but I should be able to reference the documents linked by tags from inside the "Software" item -- I just don't want to see them as first-class citizens when I browsing with everything else. This would be doubly true if I decided to actually US the Documents type moving forward.

    Good Luck! Let me know if I can be grouchy or helpful in any way with respect to the design problem. ;)

  • Ben
    Options

    I can also appreciate wanting to move the product forward, however respecting existing use cases ought to be pretty important...

    Understood.

    Also, at least the Mac version should really warn the user that they are about to break something (maybe only if some attachments exist at the time of the drag).

    We didn't really look at it as "breaking something."

    If the problem is that what you've got now is basically a bunch of tag-associations, then how about letting me hide documents with certain tags (or maybe an entire tag hierarchy) in the interface... and then making an "attachment" tag. If I try to make an attachment in the old fashioned way, it adds the "connect the document to my item" tag and an "attachment" tag automatically -- or maybe they just share an attachment-number-XYZAB tag... This is basically just using the tag engine to re-implement the old storage model.

    Something along those lines is one idea we're considering. I'm not sure how related to tags it would be, but we have discussed making it possible to have a document that doesn't appear in the Documents category.

    Good Luck! Let me know if I can be grouchy or helpful in any way with respect to the design problem. ;)

    Sounds like a plan. :)

    I appreciate your time!

    You're very welcome.

    Ben

This discussion has been closed.