Bug: Moving an Item which has an attached (linked) file breaks the link without warning!

chriswayg

Expected behavior (1Password 7 Family Subscription):
1. When I select both the item and the attachment and move them both together to another vault, they should stay linked
2. If I select only the item and try to move it, I should receive a dialog asking me, if I want to move all linked files together nwith the item
3. If for some reason the link would be broken, there should at least be a warning (before the move) or a notification (after the move) that the link(s0 have been broken

Currently I have to do the following before moving an item:
1. Check, if it has an attachment (link)
2. Select both the item and all linked documents and move them
3. Open the item which now shows (deleted item), which is factually incorrect, as the item has not been deleted!
4. Edit the item and delete every broken link
5. Click on "Link Existing" to restore every broken link
6. Save the item
7. Repeat for possibly hundreds of items when reorganizing vaults for the whole family

The current implementation is badly broken, as can be shown by the many comments since 2018.
When are you going to fix this?

chriswayg

Moving an Item which has an attached (linked) document breaks the link without warning, even when I move the item together with the linked document.

Expected behavior (1Password 7 Family Subscription):
1. When I select both the item and the attachment and move them both together to another vault, they should stay linked
2. If I select only the item and try to move it, I should receive a dialog asking me, if I want to move all linked documents together with the item
3. If for some reason the link would be broken, there should at least be a warning (before the move) or a notification (after the move) that link(s) have been broken

Currently I have to do the following before moving an item:
1. Check, if the item has an attached document (a link)
2. Select both the item and all linked documents and move them
3. Open the item which now shows (deleted item), which is factually incorrect, as the document has not been deleted!
4. Edit the item and delete every broken document link
5. Click on "Link Existing" to restore every broken document link
6. Save the item
7. Repeat for possibly hundreds of items and documents when reorganizing vaults for the whole family

This is much too cumbersome for more than a few items. The current attachment implementation is badly broken, as can be shown by the many comments since 2018.
When are you going to fix this?

---

1Password Version: 7.3.1
Extension Version: Not Provided
OS Version: macOS 10.14.5
Sync Type: 1Password.com Account

littlebobbytables

Hello @chriswayg,

So if I used the menu option to move or copy that a dialog pops up warning of the break but this dialog does not appear when you drag and drop. That's an inconsistency that does make 1Password look bad. On top of that there is also the current basic behaviour that doesn't offer any options for maintaining the link as you've suggested. So one UI (User Interface) bug and a very reasonable feature request. It turns out we've got issues filed for both so I will leave a comment that this is still very much something that needs addressed.

ref: apple-1380
ref: apple-1423

AGAlumB

@chriswayg: I get this when I right-click and move them to another vault:

Are you maybe dragging them? I think that might be where the issue lies. Let me know.

AGAlumB

Looks like you created two separate discussions. I've merged them to avoid further confusion and duplication of effort. :)

chriswayg

@brenty Naturally, I drag & drop the items; should I really expect a different behavior when using the context menu ;)

Ok, so this warning dialog is missing when doing drag & drop!

@littlebobbytables - fully agreed. Good to know that you are working on these issues.

What about this misleading notice, making you think, that the document has been lost by moving?

(from 3. above): When after moving you open the item, it now shows (deleted item) for the linked document, which is factually incorrect, as the document has not been deleted, but successfully moved! (Actually you did drop a copy in the Trash and made copy in the destination vault, which is a weird way of doing a move. No operating system does a file-move that way!)

littlebobbytables

Hi @chriswayg,

Vaults are treated as completely separate entities so it isn't like moving an item around on a single volume which would be just a pointer update. As a result a move operation copies the item and then deletes the original - it's safer that way.

One of the issues we have is about the fact that drag and drop shouldn't be different from selecting the move or copy action, 1Password's behaviour should be consistent even if there are different paths for the same task. So we've got that angle covered at least in terms of a report :smile:

The choice of words is more geared towards one cause, that can be something else we can look into. If we implement copying linked documents and maintaining the link one approach may be to prune dead links if the user doesn't wish to keep them. That would mean deleted item holds true. I'll let the developers decide what would make for intuitive and sensible behaviour.

AGAlumB

@chriswayg: Just to clarify what lil bobby said:

Vaults are treated as completely separate entities

Vaults are actually completely separate cryptographically. This is what allows you to share one vault without giving away access to all of them. The flip side of that is moving data between vaults is complex, even if it seems simple in the UI. We would like to improve the workflow of Documents and linked items in general, but need to keep all of this in mind with any change we make. Hopefully we'll be able to come up with a smoother way (from the user's, perspective, at least) of doing this. Thanks for your feedback! :)

kriro

Just moved to Family. So, do I understand this correctly that what worked flawlessly in 1PW6 local vaults, namely copying an item with attachments to another vault with all attachments intact, does no longer work with vaults on a 1PW account?!

In other words, I cannot copy or move an item with linked files from my private vault to the shared one, keeping it fully intact? Now, that'd be a bummer and a huge design flaw (or at least implementation flaw).

So, to copy an item with linked documents to a different vault should IMO implemented like this:

1. Copy original item to new vault.
2. For each of its attached documents, check if they are already present in the target vault (data-identical, i.e. search on hash, then do data-comparison on match).
3. If that document already exists in the target vault, rewrite the link in the copied item to that document.
4. If that document does not yet exist in the target vault, copy the original document from the source vault to the target vault, then relink it to the earlier copied item in the target vault.
5. Note that you may need to do this recursively, if the linked item is not a document, but another item, that again may have links.

Have I missed anything here?

It looks like abandoning "embedded attachments" in favor of linked, first-class document item relations was a move into trouble land: Item attachments served different purposes (even on a conceptual level) than item linking, and have broken the nice atomicity of an item (like a software license item with embedded key and invoice attachments - you'll never want to link that license key or invoice with any other item, and they are of no particular use on their own...).

AGAlumB

Just moved to Family. So, do I understand this correctly that what worked flawlessly in 1PW6 local vaults, namely copying an item with attachments to another vault with all attachments intact, does no longer work with vaults on a 1PW account?!

@kriro: Attachments do not exist at all in 1Password membership accounts. Those were files which were actually part of those items -- e.g. a PDF added to a Secure Note. In 1Password membership accounts, files are uploaded as Documents, which are completely separate items, which allows for more flexibility -- for example, you can link a single Document to as many other items as you want, of any type. Or have just a Document, without any other item associated with it, because you really just want the file stored in 1Password.

In other words, I cannot copy or move an item with linked files from my private vault to the shared one, keeping it fully intact? Now, that'd be a bummer and a huge design flaw (or at least implementation flaw).

But indeed, for that flexibility, we've got separate items, which is good for a lot of use cases, but if you are frequently shuffling them back and forth between vaults, it can be a pain. So we're looking into ways to maintain the links when moving between vaults (actually not possible to maintain, but more along the lines of automating re-establishing the previous setup with the new items encrypted with new keys in the new vault, if that makes sense).

Have I missed anything here?

Your suggestion is interesting, but as you correctly note the recursion could get a bit unwieldy, and it sounds like you're not accounting for the fact that users will not always want to copy/move all of the linked items -- especially recursively -- at all. That part is both a UI design challenge and a technical one. We really need to account for a wide variety of users and use cases, which further complicates things on top of the inherent technical challenges. But I do think we'll be able to come up with something. :)

It looks like abandoning "embedded attachments" in favor of linked, first-class document item relations was a move into trouble land: Item attachments served different purposes (even on a conceptual level) than item linking, and have broken the nice atomicity of an item (like a software license item with embedded key and invoice attachments - you'll never want to link that license key or invoice with any other item, and they are of no particular use on their own...).

Yes and no. We did give up some simplicity, but got a lot in return. Our job is to further build on the Documents feature to smooth over some of the rough edges in specific contexts, of which you've provided some good examples. Software licenses are a good one, though the counter example is that I don't even bother creating Software License items any more when everything is already included in a PDF or whatever I've added as a Document. But I will admit freely that part of that is just laziness, and I do think there are plenty of good reasons to improve Documents, and ways to do it. Thanks for the encouragement! :)

kriro

Thanks brenty for confirming my understanding. Unfortunately, that changed item+attachment handling in 1PW membership accounts is an absolute deal breaker for me and I had to bail out of my trial - at least for now.

I'll keep watching development, but keep using 1PW with local accounts in the meantime and Dropbox-Syncing, which also allows me to set up a family-shared vault (which is what I was looking for in a membership account), but does not have the outlined usability problems for item attachments.

Thanks,
Christian

AGAlumB

Likewise, thanks for your honest feedback. We'll continue building on the Documents feature, and hopefully you'll find it more useful in the future. :+1: