github-starred/vaultwarden
2
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-07-18 01:49:32 -05:00
Code Issues 513 Packages Projects Releases 83 Wiki Activity

[GH-ISSUE #7210] manage field in sync response always false for User-type org members despite per-collection manage permission #35596

New Issue
Closed
opened 2026-07-13 20:25:45 -05:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-07-13 20:25:45 -05:00
Owner
Copy Link

Originally created by @scrapix on GitHub (May 12, 2026).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/7210

Prerequisites

Vaultwarden Support String

Description:

When a per-collection "Manage" permission is granted to a User-type org member (type 2) via the admin panel, the /api/sync response still returns "manage": false for that
collection.

Root cause:

In src/db/models/collection.rs, to_json_details() at line 102:

is_manager && (cu.manage || (!cu.read_only && !cu.hide_passwords)),

The cu.manage value from the users_collections table is gated behind is_manager (which is only true for MembershipType::Manager, type 3). For User-type members (type 2),
the expression short-circuits to false regardless of the actual cu.manage DB value.

Expected behavior:

If a per-collection manage permission is explicitly set in the users_collections table (visible in the admin panel as "Manage collection"), it should be reflected in the
sync response for all member types — not just Managers.

Suggested fix:

Change line 102 from:
is_manager && (cu.manage || (!cu.read_only && !cu.hide_passwords)),
to:
cu.manage || (is_manager && !cu.read_only && !cu.hide_passwords),

And similarly line 108 for group-based permissions.

This preserves the existing Manager implicit-manage behavior (full read/write implies manage) while also honoring the explicitly-set cu.manage flag for all member types.

Reproduction:

  1. Create an org with a User-type member
  2. Grant "Manage collection" permission on a collection for that user in the admin panel
  3. Sync as that user → manage: false returned despite the DB storing manage: true

Version: Confirmed in current Vaultwarden source (to_json_details in src/db/models/collection.rs)

Vaultwarden Build Version

2026.4.1

Deployment method

Official Container Image

Custom deployment method

No response

Reverse Proxy

traefik

Host/Server Operating System

Linux

Operating System Version

No response

Clients

CLI

Client Version

No response

Steps To Reproduce

  1. Go to '...'
  2. Click on '....'
  3. Scroll down to '....'
  4. Click on '...'
  5. Etc '...'

Expected Result

Title: Fix: propagate per-collection manage flag for User-type org members

Body:

Summary

  • Fix manage field in sync response always returning false for User-type (type 2) org members, even when per-collection "Manage" permission is explicitly granted
  • The cu.manage / cg.manage value from users_collections / collections_groups table was gated behind is_manager check, preventing User-type members from ever seeing manage:
    true

Changes

src/db/models/collection.rs — to_json_details():

                   if let Some(cu) = cipher_sync_data.user_collections.get(&self.uuid) {
                       (
                           cu.read_only,
                           cu.hide_passwords,

  •                        is_manager && (cu.manage || (!cu.read_only && !cu.hide_passwords)),

  •                        cu.manage || (is_manager && !cu.read_only && !cu.hide_passwords),
                   )
               } else if let Some(cg) = cipher_sync_data.user_collections_groups.get(&self.uuid) {
                   (
                       cg.read_only,
                       cg.hide_passwords,

  •                        is_manager && (cg.manage || (!cg.read_only && !cg.hide_passwords)),

  •                        cg.manage || (is_manager && !cg.read_only && !cg.hide_passwords),
                   )

Rationale

The admin panel allows granting "Manage collection" to any member type, and this is stored in the users_collections.manage column. However to_json_details() only propagated
this to the sync response for Manager+ roles. This made the per-collection manage permission effectively non-functional for User-type members.

The fix honors the explicitly-set manage flag for all member types, while preserving the existing implicit behavior where Managers with full read/write access (no
read_only, no hide_passwords) also get manage: true.

Test plan

  • Grant "Manage collection" to a User-type org member via admin panel
  • Sync as that user → verify manage: true in response for that collection
  • Verify Manager implicit manage behavior still works (full read/write → manage)
  • Verify User without explicit manage still gets manage: false

Actual Result

can set a user as collection manager in admin console but not use this state on client

Logs

Screenshots or Videos

No response

Additional Context

No response

Originally created by @scrapix on GitHub (May 12, 2026). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/7210 ### Prerequisites - [x] I have searched the existing **Closed _AND_ Open** [Issues](https://github.com/dani-garcia/vaultwarden/issues?q=is%3Aissue%20) **_AND_** [Discussions](https://github.com/dani-garcia/vaultwarden/discussions?discussions_q=) - [x] I have searched and read the [documentation](https://github.com/dani-garcia/vaultwarden/wiki/) ### Vaultwarden Support String Description: When a per-collection "Manage" permission is granted to a User-type org member (type 2) via the admin panel, the /api/sync response still returns "manage": false for that collection. Root cause: In src/db/models/collection.rs, to_json_details() at line 102: is_manager && (cu.manage || (!cu.read_only && !cu.hide_passwords)), The cu.manage value from the users_collections table is gated behind is_manager (which is only true for MembershipType::Manager, type 3). For User-type members (type 2), the expression short-circuits to false regardless of the actual cu.manage DB value. Expected behavior: If a per-collection manage permission is explicitly set in the users_collections table (visible in the admin panel as "Manage collection"), it should be reflected in the sync response for all member types — not just Managers. Suggested fix: Change line 102 from: is_manager && (cu.manage || (!cu.read_only && !cu.hide_passwords)), to: cu.manage || (is_manager && !cu.read_only && !cu.hide_passwords), And similarly line 108 for group-based permissions. This preserves the existing Manager implicit-manage behavior (full read/write implies manage) while also honoring the explicitly-set cu.manage flag for all member types. Reproduction: 1. Create an org with a User-type member 2. Grant "Manage collection" permission on a collection for that user in the admin panel 3. Sync as that user → manage: false returned despite the DB storing manage: true Version: Confirmed in current Vaultwarden source (to_json_details in src/db/models/collection.rs) ### Vaultwarden Build Version 2026.4.1 ### Deployment method Official Container Image ### Custom deployment method _No response_ ### Reverse Proxy traefik ### Host/Server Operating System Linux ### Operating System Version _No response_ ### Clients CLI ### Client Version _No response_ ### Steps To Reproduce 1. Go to '...' 2. Click on '....' 3. Scroll down to '....' 4. Click on '...' 5. Etc '...' ### Expected Result Title: Fix: propagate per-collection manage flag for User-type org members Body: Summary - Fix manage field in sync response always returning false for User-type (type 2) org members, even when per-collection "Manage" permission is explicitly granted - The cu.manage / cg.manage value from users_collections / collections_groups table was gated behind is_manager check, preventing User-type members from ever seeing manage: true Changes src/db/models/collection.rs — to_json_details(): if let Some(cu) = cipher_sync_data.user_collections.get(&self.uuid) { ( cu.read_only, cu.hide_passwords, - is_manager && (cu.manage || (!cu.read_only && !cu.hide_passwords)), + cu.manage || (is_manager && !cu.read_only && !cu.hide_passwords), ) } else if let Some(cg) = cipher_sync_data.user_collections_groups.get(&self.uuid) { ( cg.read_only, cg.hide_passwords, - is_manager && (cg.manage || (!cg.read_only && !cg.hide_passwords)), + cg.manage || (is_manager && !cg.read_only && !cg.hide_passwords), ) Rationale The admin panel allows granting "Manage collection" to any member type, and this is stored in the users_collections.manage column. However to_json_details() only propagated this to the sync response for Manager+ roles. This made the per-collection manage permission effectively non-functional for User-type members. The fix honors the explicitly-set manage flag for all member types, while preserving the existing implicit behavior where Managers with full read/write access (no read_only, no hide_passwords) also get manage: true. Test plan - Grant "Manage collection" to a User-type org member via admin panel - Sync as that user → verify manage: true in response for that collection - Verify Manager implicit manage behavior still works (full read/write → manage) - Verify User without explicit manage still gets manage: false ### Actual Result can set a user as collection manager in admin console but not use this state on client ### Logs ```text ``` ### Screenshots or Videos _No response_ ### Additional Context _No response_
GiteaMirror added the bug label 2026-07-13 20:25:45 -05:00
GiteaMirror commented 2026-07-13 20:25:47 -05:00
Author
Owner
Copy Link

@BlackDex commented on GitHub (May 13, 2026):

The main reason is, because Vaultwarden doesn't support this.
There are different roles and rights for managing collections which currently are not working or break if the role is user but with manage permissions on a collection. That is why we return edit.

A lot needs to be changed to get this working properly, not just those lines.

This for me is a works as intended.

<!-- gh-comment-id:4437871416 --> @BlackDex commented on GitHub (May 13, 2026): The main reason is, because Vaultwarden doesn't support this. There are different roles and rights for managing collections which currently are not working or break if the role is user but with manage permissions on a collection. That is why we return `edit`. A lot needs to be changed to get this working properly, not just those lines. This for me is a works as intended.
GiteaMirror commented 2026-07-13 20:25:48 -05:00
Author
Owner
Copy Link

@scrapix commented on GitHub (May 13, 2026):

@BlackDex thanks for your quick feedback. I was unaware of this permission model. I thought Collection permissions were independant of user roles and permissions.
Quiete unfortunate though :(

<!-- gh-comment-id:4439678065 --> @scrapix commented on GitHub (May 13, 2026): @BlackDex thanks for your quick feedback. I was unaware of this permission model. I thought Collection permissions were independant of user roles and permissions. Quiete unfortunate though :(
GiteaMirror commented 2026-07-13 20:25:48 -05:00
Author
Owner
Copy Link

@scrapix commented on GitHub (May 13, 2026):

Then to make the UX consistent, a regular "edit" user should net be assignable as manage collection user in admin panel

<!-- gh-comment-id:4439689128 --> @scrapix commented on GitHub (May 13, 2026): Then to make the UX consistent, a regular "edit" user should net be assignable as manage collection user in admin panel
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
better for forum
bug
documentation
duplicate
enhancement
future Vault
good first issue
help wanted
low priority
notes
pull-request
Mirrored from GitHub Pull Request
 question
SSO
Third party
troubleshooting
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#35596
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?