mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-03-16 11:50:18 -05:00
[Bug] Latest testing, collections do not load (Related to PascalCase changes?) #5593
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jb2barrels on GitHub (Jun 27, 2024).
Subject of the issue
Collections tree in the filters box does not show all collections after upgrading to latest testing. (Maybe related to the latest PascalCase changes?)
Deployment environment
Install method: Docker Compose
Clients used:
Web vault
Reverse proxy and version:
Nginx Proxy Manager with SSL
Steps to reproduce
Expected behaviour
Collections tree should load under the filters section.
Example screenshot, where it shows collections do exists but do not show up in the collections tree on the left.

@BlackDex commented on GitHub (Jun 27, 2024):
Probably related to #4681, but could be something different.
@stefan0xC commented on GitHub (Jun 27, 2024):
It also happens on vault.bitwarden.com so this probably unrelated to vaultwarden (might even be intentional).
cf. https://github.com/bitwarden/clients/issues/9823
@jb2barrels commented on GitHub (Jun 27, 2024):
I was able to rollback to the June 20th build of vaultwarden (via doing a docker build) - which has the Web vault 2024.5.1 (collections issue is not present in that vaultwarden build):
8f05a90b96So it seems the admin collections issue crept in on vaultwarden between June 23rd - June 24th.
I don't see a web vault update between those dates, so I do wonder if the above is a coincidence or some recent change that was somewhat copied over from Bitwarden into Vaultwarden.
@stefan0xC commented on GitHub (Jun 28, 2024):
seems like this setting is responsible for the behavior:
a4c7fadbf4/src/db/models/organization.rs (L409)@BlackDex commented on GitHub (Jun 28, 2024):
Ah, we can set that back to false for now. And add flex/v2 later.
@stefan0xC commented on GitHub (Jun 28, 2024):
I don't think those two are that related (like I said https://github.com/dani-garcia/bw_web_builds/pull/169#issuecomment-2185324417 the new endpoint is already used instead). To actually implement flexible collections we will have to change more stuff (not sure if this is everything but that's what I've noted down so far)
/api/organizations/<org_uuid>/collections/bulk-accessendpoint for new bulk collection assignmentcollections_v2endpoint to return"unvailable": trueif the cipher becomes unavailable due to changed permissions. (edit: Or rather this might be missing from my PR. I have not really looked at it that deeply.)@BlackDex commented on GitHub (Jun 28, 2024):
Oef. That sounds to me like a Backup your database first before update situation.
@BlackDex commented on GitHub (Jun 28, 2024):
I created a PR to fix this specific issue, and a small issue i found with the new native app. #4685