[GH-ISSUE #5160] Organization groups permission on collections are not visible in 1.32.3 #18856

Closed
opened 2026-04-25 21:09:27 -05:00 by GiteaMirror · 8 comments
Owner

Originally created by @Misterbabou on GitHub (Nov 5, 2024).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/5160

Vaultwarden Support String

Your environment (Generated via diagnostics page)

  • Vaultwarden version: v1.32.3
  • Web-vault version: v2024.6.2c
  • OS/Arch: linux/x86_64
  • Running within a container: true (Base: Debian)
  • Environment settings overridden: false
  • Uses a reverse proxy: false
  • Internet access: true
  • Internet access via a proxy: false
  • DNS Check: true
  • Browser/Server Time Check: true
  • Server/NTP Time Check: n/a
  • Domain Configuration Check: false
  • HTTPS Check: true
  • Database type: MySQL
  • Database version: 11.5.2-MariaDB-ubu2404
  • Clients used:
  • Reverse proxy and version:
  • Other relevant information:

Config (Generated via diagnostics page)

Show Running Config

Environment settings which are overridden:

{
  "_duo_akey": null,
  "_enable_duo": true,
  "_enable_email_2fa": false,
  "_enable_smtp": true,
  "_enable_yubico": true,
  "_icon_service_csp": "",
  "_icon_service_url": "",
  "_ip_header_enabled": true,
  "_max_note_size": 10000,
  "_smtp_img_src": "cid:",
  "admin_ratelimit_max_burst": 3,
  "admin_ratelimit_seconds": 300,
  "admin_session_lifetime": 20,
  "admin_token": "***",
  "allowed_iframe_ancestors": "",
  "attachments_folder": "data/attachments",
  "auth_request_purge_schedule": "30 * * * * *",
  "authenticator_disable_time_drift": false,
  "data_folder": "data",
  "database_conn_init": "",
  "database_max_conns": 10,
  "database_timeout": 30,
  "database_url": "*****://****************************************************",
  "db_connection_retries": 15,
  "disable_2fa_remember": true,
  "disable_admin_token": false,
  "disable_icon_download": false,
  "domain": "*****://*********",
  "domain_origin": "*****://*********",
  "domain_path": "",
  "domain_set": true,
  "duo_context_purge_schedule": "30 * * * * *",
  "duo_host": null,
  "duo_ikey": null,
  "duo_skey": null,
  "duo_use_iframe": false,
  "email_2fa_auto_fallback": false,
  "email_2fa_enforce_on_verified_invite": false,
  "email_attempts_limit": 3,
  "email_change_allowed": true,
  "email_expiration_time": 600,
  "email_token_size": 6,
  "emergency_access_allowed": false,
  "emergency_notification_reminder_schedule": "0 3 * * * *",
  "emergency_request_timeout_schedule": "0 7 * * * *",
  "enable_db_wal": true,
  "enable_websocket": true,
  "enforce_single_org_with_reset_pw_policy": false,
  "event_cleanup_schedule": "0 10 0 * * *",
  "events_days_retain": 7,
  "experimental_client_feature_flags": "fido2-vault-credentials",
  "extended_logging": true,
  "helo_name": null,
  "hibp_api_key": null,
  "http_request_block_non_global_ips": true,
  "http_request_block_regex": null,
  "icon_blacklist_non_global_ips": true,
  "icon_blacklist_regex": null,
  "icon_cache_folder": "data/icon_cache",
  "icon_cache_negttl": 259200,
  "icon_cache_ttl": 2592000,
  "icon_download_timeout": 10,
  "icon_redirect_code": 302,
  "icon_service": "internal",
  "incomplete_2fa_schedule": "30 * * * * *",
  "incomplete_2fa_time_limit": 3,
  "increase_note_size_limit": false,
  "invitation_expiration_hours": 120,
  "invitation_org_name": "Vaultwarden GO/PST",
  "invitations_allowed": true,
  "ip_header": "X-Real-IP",
  "job_poll_interval_ms": 30000,
  "log_file": null,
  "log_level": "info",
  "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
  "login_ratelimit_max_burst": 10,
  "login_ratelimit_seconds": 60,
  "org_attachment_limit": null,
  "org_creation_users": "***************************",
  "org_events_enabled": true,
  "org_groups_enabled": true,
  "password_hints_allowed": true,
  "password_iterations": 600000,
  "push_enabled": false,
  "push_identity_uri": "https://identity.bitwarden.com",
  "push_installation_id": "***",
  "push_installation_key": "***",
  "push_relay_uri": "https://push.bitwarden.com",
  "reload_templates": false,
  "require_device_email": false,
  "rsa_key_filename": "data/rsa_key",
  "send_purge_schedule": "0 5 * * * *",
  "sendmail_command": null,
  "sends_allowed": true,
  "sends_folder": "data/sends",
  "show_password_hint": false,
  "signups_allowed": true,
  "signups_domains_whitelist": "",
  "signups_verify": false,
  "signups_verify_resend_limit": 6,
  "signups_verify_resend_time": 3600,
  "smtp_accept_invalid_certs": false,
  "smtp_accept_invalid_hostnames": false,
  "smtp_auth_mechanism": null,
  "smtp_debug": false,
  "smtp_embed_images": true,
  "smtp_explicit_tls": null,
  "smtp_from": "",
  "smtp_from_name": "Vaultwarden",
  "smtp_host": null,
  "smtp_password": null,
  "smtp_port": 587,
  "smtp_security": "starttls",
  "smtp_ssl": null,
  "smtp_timeout": 15,
  "smtp_username": null,
  "templates_folder": "data/templates",
  "tmp_folder": "data/tmp",
  "trash_auto_delete_days": 15,
  "trash_purge_schedule": "0 5 0 * * *",
  "use_sendmail": false,
  "use_syslog": false,
  "user_attachment_limit": null,
  "user_send_limit": null,
  "web_vault_enabled": true,
  "web_vault_folder": "web-vault/",
  "yubico_client_id": null,
  "yubico_secret_key": null,
  "yubico_server": null
}

Vaultwarden Build Version

v1.32.3

Deployment method

Official Container Image

Custom deployment method

No response

Reverse Proxy

No proxy

Host/Server Operating System

Linux

Operating System Version

Ubuntu 22.04

Clients

Web Vault

Client Version

No response

Steps To Reproduce

  1. Ensure you are on 1.32.3 (bug is not present on 1.32.2)
  2. Create an organization
  3. Create a new Collection
  4. Create a new group
  5. Edit permission on the group to give permission you want on the new collection
  6. Click Save
  7. Now check the group permission, the permission column is blank (see screenshot below)

(previously created group before 1.32.3 upgrade have the same issue rollback on 1.32.2 show the permission column again)

Expected Result

The permission column should print Can View, Can Edit... depending on previous set permission

Actual Result

The collumn is blank but permission previously set are working.

Logs

No response

Screenshots or Videos

image

Additional Context

No response

Originally created by @Misterbabou on GitHub (Nov 5, 2024). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/5160 ### Vaultwarden Support String ### Your environment (Generated via diagnostics page) * Vaultwarden version: v1.32.3 * Web-vault version: v2024.6.2c * OS/Arch: linux/x86_64 * Running within a container: true (Base: Debian) * Environment settings overridden: false * Uses a reverse proxy: false * Internet access: true * Internet access via a proxy: false * DNS Check: true * Browser/Server Time Check: true * Server/NTP Time Check: n/a * Domain Configuration Check: false * HTTPS Check: true * Database type: MySQL * Database version: 11.5.2-MariaDB-ubu2404 * Clients used: * Reverse proxy and version: * Other relevant information: ### Config (Generated via diagnostics page) <details><summary>Show Running Config</summary> **Environment settings which are overridden:** ```json { "_duo_akey": null, "_enable_duo": true, "_enable_email_2fa": false, "_enable_smtp": true, "_enable_yubico": true, "_icon_service_csp": "", "_icon_service_url": "", "_ip_header_enabled": true, "_max_note_size": 10000, "_smtp_img_src": "cid:", "admin_ratelimit_max_burst": 3, "admin_ratelimit_seconds": 300, "admin_session_lifetime": 20, "admin_token": "***", "allowed_iframe_ancestors": "", "attachments_folder": "data/attachments", "auth_request_purge_schedule": "30 * * * * *", "authenticator_disable_time_drift": false, "data_folder": "data", "database_conn_init": "", "database_max_conns": 10, "database_timeout": 30, "database_url": "*****://****************************************************", "db_connection_retries": 15, "disable_2fa_remember": true, "disable_admin_token": false, "disable_icon_download": false, "domain": "*****://*********", "domain_origin": "*****://*********", "domain_path": "", "domain_set": true, "duo_context_purge_schedule": "30 * * * * *", "duo_host": null, "duo_ikey": null, "duo_skey": null, "duo_use_iframe": false, "email_2fa_auto_fallback": false, "email_2fa_enforce_on_verified_invite": false, "email_attempts_limit": 3, "email_change_allowed": true, "email_expiration_time": 600, "email_token_size": 6, "emergency_access_allowed": false, "emergency_notification_reminder_schedule": "0 3 * * * *", "emergency_request_timeout_schedule": "0 7 * * * *", "enable_db_wal": true, "enable_websocket": true, "enforce_single_org_with_reset_pw_policy": false, "event_cleanup_schedule": "0 10 0 * * *", "events_days_retain": 7, "experimental_client_feature_flags": "fido2-vault-credentials", "extended_logging": true, "helo_name": null, "hibp_api_key": null, "http_request_block_non_global_ips": true, "http_request_block_regex": null, "icon_blacklist_non_global_ips": true, "icon_blacklist_regex": null, "icon_cache_folder": "data/icon_cache", "icon_cache_negttl": 259200, "icon_cache_ttl": 2592000, "icon_download_timeout": 10, "icon_redirect_code": 302, "icon_service": "internal", "incomplete_2fa_schedule": "30 * * * * *", "incomplete_2fa_time_limit": 3, "increase_note_size_limit": false, "invitation_expiration_hours": 120, "invitation_org_name": "Vaultwarden GO/PST", "invitations_allowed": true, "ip_header": "X-Real-IP", "job_poll_interval_ms": 30000, "log_file": null, "log_level": "info", "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f", "login_ratelimit_max_burst": 10, "login_ratelimit_seconds": 60, "org_attachment_limit": null, "org_creation_users": "***************************", "org_events_enabled": true, "org_groups_enabled": true, "password_hints_allowed": true, "password_iterations": 600000, "push_enabled": false, "push_identity_uri": "https://identity.bitwarden.com", "push_installation_id": "***", "push_installation_key": "***", "push_relay_uri": "https://push.bitwarden.com", "reload_templates": false, "require_device_email": false, "rsa_key_filename": "data/rsa_key", "send_purge_schedule": "0 5 * * * *", "sendmail_command": null, "sends_allowed": true, "sends_folder": "data/sends", "show_password_hint": false, "signups_allowed": true, "signups_domains_whitelist": "", "signups_verify": false, "signups_verify_resend_limit": 6, "signups_verify_resend_time": 3600, "smtp_accept_invalid_certs": false, "smtp_accept_invalid_hostnames": false, "smtp_auth_mechanism": null, "smtp_debug": false, "smtp_embed_images": true, "smtp_explicit_tls": null, "smtp_from": "", "smtp_from_name": "Vaultwarden", "smtp_host": null, "smtp_password": null, "smtp_port": 587, "smtp_security": "starttls", "smtp_ssl": null, "smtp_timeout": 15, "smtp_username": null, "templates_folder": "data/templates", "tmp_folder": "data/tmp", "trash_auto_delete_days": 15, "trash_purge_schedule": "0 5 0 * * *", "use_sendmail": false, "use_syslog": false, "user_attachment_limit": null, "user_send_limit": null, "web_vault_enabled": true, "web_vault_folder": "web-vault/", "yubico_client_id": null, "yubico_secret_key": null, "yubico_server": null } ``` </details> ### Vaultwarden Build Version v1.32.3 ### Deployment method Official Container Image ### Custom deployment method _No response_ ### Reverse Proxy No proxy ### Host/Server Operating System Linux ### Operating System Version Ubuntu 22.04 ### Clients Web Vault ### Client Version _No response_ ### Steps To Reproduce 1. Ensure you are on 1.32.3 (bug is not present on 1.32.2) 2. Create an organization 3. Create a new Collection 4. Create a new group 5. Edit permission on the group to give permission you want on the new collection 6. Click Save 7. Now check the group permission, the permission column is blank (see screenshot below) (previously created group before 1.32.3 upgrade have the same issue rollback on 1.32.2 show the permission column again) ### Expected Result The permission column should print `Can View`, `Can Edit`... depending on previous set permission ### Actual Result The collumn is blank but permission previously set are working. ### Logs _No response_ ### Screenshots or Videos ![image](https://github.com/user-attachments/assets/0475f212-de36-4bb0-9ce0-c0802cecf9fd) ### Additional Context _No response_
GiteaMirror added the bug label 2026-04-25 21:09:27 -05:00
Author
Owner

@Misterbabou commented on GitHub (Nov 11, 2024):

For info : still having the same issue on v1.32.4

<!-- gh-comment-id:2467513059 --> @Misterbabou commented on GitHub (Nov 11, 2024): For info : still having the same issue on v1.32.4
Author
Owner

@BlackDex commented on GitHub (Nov 11, 2024):

Which wouldn't be strange as that is not addressed

<!-- gh-comment-id:2467524420 --> @BlackDex commented on GitHub (Nov 11, 2024): Which wouldn't be strange as that is not addressed
Author
Owner

@Misterbabou commented on GitHub (Nov 12, 2024):

It wasn't a criticism; I just wanted to provide as much information as possible since I was referring to the previous version in my first message :)

<!-- gh-comment-id:2470052575 --> @Misterbabou commented on GitHub (Nov 12, 2024): It wasn't a criticism; I just wanted to provide as much information as possible since I was referring to the previous version in my first message :)
Author
Owner

@stefan0xC commented on GitHub (Nov 12, 2024):

Using web-v2024.10.5 (https://github.com/dani-garcia/bw_web_builds/pull/182) it seems to work as expected:
image

As far as I've looked into it adding support for the can manage permission for groups in #5095 is responsible that it shows up in v1.32.3 because earlier web-vaults seems to be unable to handle if this evaluates to true for groups: adb21d5c1a/src/db/models/group.rs (L85)

edit: after looking again, I think that it's incorrect to use the users role for deciding the value of the group, so we should probably revert that to return just false for now.

<!-- gh-comment-id:2471772702 --> @stefan0xC commented on GitHub (Nov 12, 2024): Using `web-v2024.10.5` (https://github.com/dani-garcia/bw_web_builds/pull/182) <del>it seems to work as expected</del>: ![image](https://github.com/user-attachments/assets/dad2ee72-5b30-4df7-b7ed-d1aaf3cab619) As far as I've looked into it adding support for the can manage permission for groups in #5095 is responsible that it shows up in `v1.32.3` because earlier web-vaults seems to be unable to handle if this evaluates to `true` for groups: https://github.com/dani-garcia/vaultwarden/blob/adb21d5c1acfef9bd06d1ad9cdf3b916b38b201b/src/db/models/group.rs#L85 edit: after looking again, I think that it's incorrect to use the users role for deciding the value of the group, so we should probably revert that to return just `false` for now.
Author
Owner

@BlackDex commented on GitHub (Nov 12, 2024):

Well i think it is correct. Admins and owners are allowed to manage all groups and collections. This is also a feature option in Bitwarden. But to stay compatible with older versions and ease of working granting admins and owners full access is the right way for now.

Without this check and only returning false would make managing groups and collections break.

The only way to fix this now it's reverting the web-vault to en earlier version.

I'm working on comparing Bitwarden and Vaultwarden regarding this. But it takes a lot of time and checking and validations including making sure it keeps working if someone reverts back to an older version.

<!-- gh-comment-id:2471823717 --> @BlackDex commented on GitHub (Nov 12, 2024): Well i think it is correct. Admins and owners are allowed to manage all groups and collections. This is also a feature option in Bitwarden. But to stay compatible with older versions and ease of working granting admins and owners full access is the right way for now. Without this check and only returning false would make managing groups and collections break. The only way to fix this now it's reverting the web-vault to en earlier version. I'm working on comparing Bitwarden and Vaultwarden regarding this. But it takes a lot of time and checking and validations including making sure it keeps working if someone reverts back to an older version.
Author
Owner

@stefan0xC commented on GitHub (Nov 12, 2024):

Without this check and only returning false would make managing groups and collections break.

hm... I'll test that tomorrow.

<!-- gh-comment-id:2471828823 --> @stefan0xC commented on GitHub (Nov 12, 2024): > Without this check and only returning false would make managing groups and collections break. hm... I'll test that tomorrow.
Author
Owner

@BlackDex commented on GitHub (Nov 12, 2024):

same here. The logic regarding the link between groups and collections is complex, more then it should be unfortunately.

<!-- gh-comment-id:2471835050 --> @BlackDex commented on GitHub (Nov 12, 2024): same here. The logic regarding the link between groups and collections is complex, more then it should be unfortunately.
Author
Owner

@stefan0xC commented on GitHub (Nov 14, 2024):

Yeah.

With web-v2024.6.2 the permissions don't seem to be listed in the Admin Console in the collections overview, but I think this a bug in the web-vault (it might be that we don't return the correct listing but as long that this is just a visual issue I don't think it's that important).
image
(update: seems to be only the Can edit permission that is not shown)

I've also just tried it with the new web-v2024.11.0 web-vault and it throws an error when I try to look at a group, so something seems to have changed again (but given it's a missing user error it might be unrelated to this change).

[2024-11-13 16:10:57.768][request][INFO] GET /api/organizations/152bd996-19f9-40ee-b991-e52333a7e719/collections/details
[2024-11-13 16:10:57.772][response][INFO] (get_org_collections_details) GET /api/organizations/<org_id>/collections/details => 200 OK
[2024-11-13 16:10:57.782][request][INFO] GET /api/organizations/152bd996-19f9-40ee-b991-e52333a7e719/users/mini-details
[2024-11-13 16:10:57.783][request][INFO] GET /api/organizations/152bd996-19f9-40ee-b991-e52333a7e719/groups/41917ddc-7cf7-47d0-bd7f-7b24d21c2b71/details
[2024-11-13 16:10:57.783][request][INFO] GET /api/organizations/152bd996-19f9-40ee-b991-e52333a7e719/groups/41917ddc-7cf7-47d0-bd7f-7b24d21c2b71/users
[2024-11-13 16:10:57.784][vaultwarden::api::core::organizations][ERROR] The specified user isn't a member of the organization
[2024-11-13 16:10:57.784][response][INFO] (get_user) GET /api/organizations/<org_id>/users/<org_user_id>?<data..> => 400 Bad Request
[2024-11-13 16:10:57.784][response][INFO] (get_group_details) GET /api/organizations/<_org_id>/groups/<group_id>/details => 200 OK
[2024-11-13 16:10:57.785][response][INFO] (get_group_users) GET /api/organizations/<_org_id>/groups/<group_id>/users => 200 OK
<!-- gh-comment-id:2476133002 --> @stefan0xC commented on GitHub (Nov 14, 2024): Yeah. With `web-v2024.6.2` the permissions don't seem to be listed in the Admin Console in the collections overview, but I think this a bug in the web-vault (it might be that we don't return the correct listing but as long that this is just a visual issue I don't think it's that important). ![image](https://github.com/user-attachments/assets/d8e6761f-d4da-437a-aa37-1173e91f94fa) (update: seems to be only the `Can edit` permission that is not shown) I've also just tried it with the new `web-v2024.11.0` web-vault and it throws an error when I try to look at a group, so something seems to have changed again (but given it's a missing user error it might be unrelated to this change). ``` [2024-11-13 16:10:57.768][request][INFO] GET /api/organizations/152bd996-19f9-40ee-b991-e52333a7e719/collections/details [2024-11-13 16:10:57.772][response][INFO] (get_org_collections_details) GET /api/organizations/<org_id>/collections/details => 200 OK [2024-11-13 16:10:57.782][request][INFO] GET /api/organizations/152bd996-19f9-40ee-b991-e52333a7e719/users/mini-details [2024-11-13 16:10:57.783][request][INFO] GET /api/organizations/152bd996-19f9-40ee-b991-e52333a7e719/groups/41917ddc-7cf7-47d0-bd7f-7b24d21c2b71/details [2024-11-13 16:10:57.783][request][INFO] GET /api/organizations/152bd996-19f9-40ee-b991-e52333a7e719/groups/41917ddc-7cf7-47d0-bd7f-7b24d21c2b71/users [2024-11-13 16:10:57.784][vaultwarden::api::core::organizations][ERROR] The specified user isn't a member of the organization [2024-11-13 16:10:57.784][response][INFO] (get_user) GET /api/organizations/<org_id>/users/<org_user_id>?<data..> => 400 Bad Request [2024-11-13 16:10:57.784][response][INFO] (get_group_details) GET /api/organizations/<_org_id>/groups/<group_id>/details => 200 OK [2024-11-13 16:10:57.785][response][INFO] (get_group_users) GET /api/organizations/<_org_id>/groups/<group_id>/users => 200 OK ```
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#18856