Collections and sharing

A collection is the unit of permission. Sharing is granting a collection to someone, never copying an entry to them. Whoever has a collection can open every entry in it.

Create a collection

1. Go to Collections.
2. Under New collection, type a Collection name and press Create.

The collection name is stored in the clear, because the server has to show it on the permissions screen to people who do not hold its key. Everything inside it is encrypted. Do not put a secret in a name.

Creating collections needs the owner or admin role.

Collections inside collections

New inside creates a collection inside another; it needs the manage permission on the parent. Everyone who can open the parent can open the child, and that cannot be revoked separately. If you need to give it to fewer people, create it at the top level instead.

Give access

1. Press Access on the collection.
2. In Choose a person…, pick who.
3. Choose the permission and press Grant.

• use fills and copies without showing values.
• view reads them.
• edit changes them.
• manage also shares the collection with others.

Next to the permission, History lets them see what a value used to be, and Restore lets them go back to one. Both are off unless you tick them: History needs view or higher, Restore needs edit and brings History with it, and manage has both. You can change them later on the same row. Turning History off stops sending old values; it cannot take back the ones a device already received.

If someone has several grants — directly and through a group — the highest one counts. There is no explicit deny.

Granting happens in your browser: it wraps the collection's key for the other person. That is why you need to hold the key yourself, and why the other person must have set a master password first — until then they appear as “no vault yet” and there is no key to wrap for them.

Remove access

Remove next to a grant stops that person's future syncs. The app marks every entry in the collection for rotation.

Removing access does not take back the copy they already have. Revoking is not rotating: change the passwords marked “◷ rotation pending” on each site, and then in the vault.

Groups

Groups are created in Admin. This screen lists the grants a group already has, but granting a collection to a group from here is not available yet.

Delete a collection

Delete on a collection, then Delete it, deletes it with all its entries, and everyone it was granted to loses it. It needs manage.

It also takes the collections inside it, with their entries. That is not a convenience: a nested collection's key is wrapped with its parent's, so leaving it behind would leave a collection nobody can open. The confirmation says how many go.

Devices that already synced the collection keep their copy. Deleting removes it from the vault; it does not reach into anyone's device.

The trash

Deleting an entry does not delete it on the server: it is marked and its content is kept. At the bottom of Collections, under Trash, choose a collection, and Restore brings the entry back with its fields. It needs edit on that collection — the same permission it took to delete it.

An entry is listed without a name, and without a button, when this browser does not hold that collection's key. That is not a fault: the name is encrypted, and from here it cannot be opened.

Deleting a collection has its own trash, under Deleted collections, just below. It needs the owner or admin role rather than a permission on the collection — deleting one cuts its grants, so there is no permission left to check. Nothing there needs a key either: a collection's name is stored in the clear, unlike an entry's.

Restore brings the collection back with the collections that were inside it and with every entry that delete took. Entries somebody had thrown away before that stay in the trash, which is where they were put.

It does not bring back anybody else's access. Restoring returns the collection and your own grant on it; everyone who had it has to be granted it again from Access. The list says how many grants stay revoked before you press anything. The other way round would hand someone their access back with nobody deciding it a second time — and whoever deleted the collection to cut that access would never be told.

A collection can refuse to come back, and the list says why. If the collection it was inside is still deleted, restore that one first — this one's key is wrapped with its key. If another collection now uses its name, rename that one first. And a top-level collection can only be restored by someone who held it directly: its key lives in its grants, and the grants the delete cut do not come back on their own.

Nothing empties either list on its own, and no deadline is promised: they show what the server still holds. What may already be gone are a field's older versions, which retention trims separately.