[Bug] Latest testing, collections do not load (Related to PascalCase changes?) #5593

Closed
opened 2026-03-07 20:30:58 -06:00 by GiteaMirror · 8 comments
Owner

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

  • vaultwarden version: testing (Latest) - As of June 27 2024
  • 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.
image

Originally created by @jb2barrels on GitHub (Jun 27, 2024). <!-- # ### NOTE: Please update to the latest version of vaultwarden before reporting an issue! This saves you and us a lot of time and troubleshooting. See: * https://github.com/dani-garcia/vaultwarden/issues/1180 * https://github.com/dani-garcia/vaultwarden/wiki/Updating-the-vaultwarden-image # ### --> <!-- Please fill out the following template to make solving your problem easier and faster for us. This is only a guideline. If you think that parts are unnecessary for your issue, feel free to remove them. Remember to hide/redact personal or confidential information, such as passwords, IP addresses, and DNS names as appropriate. --> ### Subject of the issue <!-- Describe your issue here. --> 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 <!-- ========================================================================================= Preferably, use the `Generate Support String` button on the admin page's Diagnostics tab. That will auto-generate most of the info requested in this section. ========================================================================================= --> <!-- The version number, obtained from the logs (at startup) or the admin diagnostics page --> <!-- This is NOT the version number shown on the web vault, which is versioned separately from vaultwarden --> <!-- Remember to check if your issue exists on the latest version first! --> * vaultwarden version: testing (Latest) - As of June 27 2024 <!-- How the server was installed: Docker image, OS package, built from source, etc. --> * Install method: Docker Compose * Clients used: <!-- web vault, desktop, Android, iOS, etc. (if applicable) --> Web vault * Reverse proxy and version: <!-- if applicable --> Nginx Proxy Manager with SSL ### Steps to reproduce <!-- Tell us how to reproduce this issue. What parameters did you set (differently from the defaults) and how did you start vaultwarden? --> ### Expected behaviour <!-- Tell us what you expected to happen --> 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. ![image](https://github.com/dani-garcia/vaultwarden/assets/129100561/8b8bcaa5-628d-49fc-99e7-2d17abb1bb26)
Author
Owner

@BlackDex commented on GitHub (Jun 27, 2024):

Probably related to #4681, but could be something different.

@BlackDex commented on GitHub (Jun 27, 2024): Probably related to #4681, but could be something different.
Author
Owner

@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

@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
Author
Owner

@jb2barrels commented on GitHub (Jun 27, 2024):

It also happens on vault.bitwarden.com so this probably unrelated to vaultwarden (might even be intentional). cf. bitwarden/clients#9823

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):
8f05a90b96

So 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.

@jb2barrels commented on GitHub (Jun 27, 2024): > It also happens on vault.bitwarden.com so this probably unrelated to vaultwarden (might even be intentional). cf. [bitwarden/clients#9823](https://github.com/bitwarden/clients/issues/9823) 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): https://github.com/dani-garcia/vaultwarden/commit/8f05a90b96adfe06722d01510923759fe61a8bd6 So 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.
Author
Owner

@stefan0xC commented on GitHub (Jun 28, 2024):

seems like this setting is responsible for the behavior: a4c7fadbf4/src/db/models/organization.rs (L409)

@stefan0xC commented on GitHub (Jun 28, 2024): seems like this setting is responsible for the behavior: https://github.com/dani-garcia/vaultwarden/blob/a4c7fadbf4ffa242fb78ebd152080028e7f2993c/src/db/models/organization.rs#L409
Author
Owner

@BlackDex commented on GitHub (Jun 28, 2024):

Ah, we can set that back to false for now. And add flex/v2 later.

@BlackDex commented on GitHub (Jun 28, 2024): Ah, we can set that back to false for now. And add flex/v2 later.
Author
Owner

@stefan0xC commented on GitHub (Jun 28, 2024):

Ah, we can set that back to false for now. And add flex/v2 later.

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)

  • Implement Custom User Permissions
  • Deprecate Manager role and write migration to set new "can manage" permission over assigned collections.
  • Deprecate "Access All" Flag and write migration to apply "can manage" permission to all collections.
  • Add new /api/organizations/<org_uuid>/collections/bulk-access endpoint for new bulk collection assignment
  • Support option to limit creation/deletion of collections to owners/admins.
  • Adapt the collections_v2 endpoint to return "unvailable": true if 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.)
@stefan0xC commented on GitHub (Jun 28, 2024): > Ah, we can set that back to false for now. And add flex/v2 later. 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) - [ ] Implement Custom User Permissions - [ ] Deprecate Manager role and write migration to set new "can manage" permission over assigned collections. - [ ] Deprecate "Access All" Flag and write migration to apply "can manage" permission to all collections. - [ ] Add new `/api/organizations/<org_uuid>/collections/bulk-access` endpoint for new bulk collection assignment - [ ] Support option to limit creation/deletion of collections to owners/admins. - [ ] Adapt the `collections_v2` endpoint to return `"unvailable": true` if 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.)
Author
Owner

@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): Oef. That sounds to me like a **Backup your database first before update** situation.
Author
Owner

@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

@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
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#5593