recursive folder / collection delete missing fk delete?

[hi-ko]

I installed vaultwarden using postgresql as db backend and imported several keepass xmls having a complex folder structure.
When I now try to delete a folder or collection having child folders/collection all the childs appear after deletion on root level.
On the database I realized that the foreign key constraints do not have an on delete action. e.g.

CREATE TABLE "ciphers_collections" (
    "cipher_uuid" VARCHAR(40) NOT NULL,
    "collection_uuid" VARCHAR(40) NOT NULL,
    PRIMARY KEY ("cipher_uuid", "collection_uuid"),
    CONSTRAINT "ciphers_collections_cipher_uuid_fkey" FOREIGN KEY ("cipher_uuid") REFERENCES "ciphers" ("uuid") ON UPDATE NO ACTION ON DELETE NO ACTION,
    CONSTRAINT "ciphers_collections_collection_uuid_fkey" FOREIGN KEY ("collection_uuid") REFERENCES "collections" ("uuid") ON UPDATE NO ACTION ON DELETE NO ACTION
)

shouldn't these fk contstraints instead be in general ON DELETE CASCADE to always recursive delete?

Where are the contstraints defined in code? In https://github.com/dani-garcia/vaultwarden/tree/main/migrations/postgresql I could not find any constraint.

[BlackDex]

Folders and Collections have no link at all on the server side. They are just single entries with encrypted names which the server is unable to decrypt.

The clients handle nesting by splitting on /.
Ciphers do not belong to any collection or folder, it is more of a simple label for those ciphers, and deleting any collection or folder should not delete any cipher linked to it.

So, this is a works as intended.

[hi-ko]

thanks for the prompt reply!
when there is no connection for collections/ciphers on the server side what is the use for the cross table ciphers_collections with the cipher and collection uuids then?

I find it a bit unexpected that subelements aren't deleted recursively; or rather, I didn't expect that deleting a collection with subelements would suddenly cause the subelements to appear at the root level.

[BlackDex]

It's just a foreign key connection. Those should ensure that records in the folders and collections tables only hold reference to ciphers which really exists. Trying to delete a cipher without first deleting the folder and collection records should result in an error.

[BlackDex]

Also read https://bitwarden.com/help/folders/#nested-folders

Same applies on collections.

[hi-ko]

thanks for that clarification. So most is by design from bitwarden and nothing which could be changed in vaultwarden.

When coming from keepass it's a bit odd when teams use a deep folder structure which then does not support something like inheritance for the permissions like in a filesystem or referencing like in keepass.

What possibly could be enhanced on the vaultwarden server is the way how to delete a collection / folder. Having an option for a recursive delete would avoid a lot of trouble. The same does apply for renaming. No user is aware that removing or renaming a collection/folder may create a big chaos, having all the children on the root level afterwards. If not possible on the api level maybe in the web/admin client?

People may restructure their keepass db(s) by only keeping as few folders as possible and which may need different permissions before importing them into vaultwarden's organisations since folders will get collections without permission inheritance and no easy way to restructure.

A very nice feature would be something like a listener on the collection/folder to run a script with context on CRUD-events but if the server has not even knowledge about collection/folder names and permissions set, it would be hard to implement this of course ...

Thanks anyway for your prompt feedback and patient explanations!

[BlackDex]

What possibly could be enhanced on the vaultwarden server is the way how to delete a collection / folder. Having an option for a recursive delete would avoid a lot of trouble. The same does apply for renaming. No user is aware that removing or renaming a collection/folder may create a big chaos, having all the children on the root level afterwards. If not possible on the api level maybe in the web/admin client?

That isn't possible, the server side has no way of knowing it is a recursive folder or collection. As said, the clients split it by /, and the server can't decrypt these values, so no way to do this. This has to become a client side feature supported by Bitwarden.

[hi-ko]

got it thanks 👍