Owners and Admins should be able to hide collections from there main vault overview/filter. #1512

New Issue

OVERLORD · 2025-10-09T17:17:45+03:00

OVERLORD commented

2025-10-09 17:17:45 +03:00

Originally created by @BlackDex on GitHub.

Subject of the issue

Owners and Admins of Organizations should be able to hide collections from there Filters section as upstream calls it.
You are able to uncheck the checkboxes when managing peoples even on owners and admins when you select the This user can access only the selected collections.. This doesn't prevent a user with owner or admin level privileges to still access them, but it should hide those collections from the main vault overview.

Also hiding and read-only checkboxes seem to work. But only when you are not viewing those items via the organization page.

Your environment

Using Docker: false
Bitwarden_rs version: v1.18.0
Web-vault version: v2.17.1
DNS Check: true
Time Check: true
Domain Check: false
Database type: SQLite
Clients used: web-vault
Reverse proxy and version: n/a
Other relevant information: n/a

Steps to reproduce

Go to the organization.
Click on Manage > People
Select a user, make him admin or owner
Select the option: This user can access only the selected collections.
Check and uncheck some collections.
Using that user go to your main vault overview, and that user should only see the checked collections.
Also, that user should only be able to view passwords, or prevent to update shared items opened from his main vault overview. But should be able to do that when opened via the organizations overview.

Expected behaviour

Only see the selected collections.

Actual behaviour

Seeing all collections

Also see: https://bitwarden.com/help/article/user-types-access-control/#access-control
Where it states this behavior

Originally created by @BlackDex on GitHub. ### Subject of the issue Owners and Admins of Organizations should be able to hide collections from there _Filters section_ as upstream calls it. You are able to uncheck the checkboxes when managing peoples even on owners and admins when you select the `This user can access only the selected collections.`. This doesn't prevent a user with owner or admin level privileges to still access them, but it should hide those collections from the main vault overview. Also hiding and read-only checkboxes seem to work. But only when you are not viewing those items via the organization page. ### Your environment * Using Docker: false * Bitwarden_rs version: v1.18.0 * Web-vault version: v2.17.1 * DNS Check: true * Time Check: true * Domain Check: false * Database type: SQLite * Clients used: web-vault * Reverse proxy and version: n/a * Other relevant information: n/a ### Steps to reproduce 1. Go to the organization. 2. Click on Manage > People 3. Select a user, make him admin or owner 4. Select the option: This user can access only the selected collections. 5. Check and uncheck some collections. 6. Using that user go to your main vault overview, and that user should only see the checked collections. 7. Also, that user should only be able to view passwords, or prevent to update shared items opened from his main vault overview. But should be able to do that when opened via the organizations overview. ### Expected behaviour Only see the selected collections. ### Actual behaviour Seeing all collections Also see: https://bitwarden.com/help/article/user-types-access-control/#access-control Where it states this behavior

OVERLORD added the enhancement low priority bug labels 2025-10-09 17:17:45 +03:00

OVERLORD closed this issue

2025-10-09 17:17:46 +03:00

OVERLORD commented

2025-10-09 17:17:48 +03:00

@assid2 commented on GitHub:

I think that is different, but not sure.
Also, it could be that i have created a regression if it was working before when i added the manager support.
Also it currently logs you out if you click on the collection and have no permission to view it

@assid2 commented on GitHub: > I think that is different, but not sure. > Also, it could be that i have created a regression if it was working before when i added the manager support. Also it currently logs you out if you click on the collection and have no permission to view it

OVERLORD commented

2025-10-09 17:17:48 +03:00

@BlackDex commented on GitHub:

@assid2 i just tried this again, and I am not able to reproduce this issue anymore for some reason.
Could you please test and verify this with the current testing tagged version (which is just released a few minutes/hours ago?

@BlackDex commented on GitHub: @assid2 i just tried this again, and I am not able to reproduce this issue anymore for some reason. Could you please test and verify this with the current `testing` tagged version (which is just released a few minutes/hours ago?

OVERLORD commented

2025-10-09 17:17:48 +03:00

@BlackDex commented on GitHub:

I do see some other logic issue compared to upstream.
There when opening an item from the main overview (first page after login) it doesn't matter if you are admin or owner (except if you are owner of that specific cipher i think) and it is configured that you have read-only access, you shouldn't be able to save that item. When opened/saved via the org overview you should be able.

This could be fixed if we are going to check the entry-point of the request. But for now i don't see that as a big issue.

@BlackDex commented on GitHub: I do see some other logic issue compared to upstream. There when opening an item from the main overview (first page after login) it doesn't matter if you are admin or owner (except if you are owner of that specific cipher i think) and it is configured that you have read-only access, you shouldn't be able to save that item. When opened/saved via the org overview you should be able. This could be fixed if we are going to check the entry-point of the request. But for now i don't see that as a big issue.

OVERLORD commented

2025-10-09 17:17:49 +03:00

@BlackDex commented on GitHub:

I think that is different, but not sure.
Also, it could be that i have created a regression if it was working before when i added the manager support.

@BlackDex commented on GitHub: I think that is different, but not sure. Also, it could be that i have created a regression if it was working before when i added the manager support.

OVERLORD commented

2025-10-09 17:17:49 +03:00

@jjlin commented on GitHub:

Is this different from #1123? AFAIK, that was fixed before, but perhaps some other change (either in bitwarden_rs or upstream) has caused a regression.

@jjlin commented on GitHub: Is this different from #1123? AFAIK, that was fixed before, but perhaps some other change (either in bitwarden_rs or upstream) has caused a regression.

OVERLORD commented

2025-10-09 17:17:50 +03:00

@jjlin commented on GitHub:

I didn't see any issues with hidden collections being displayed, but going to the Manage tab for the org, clicking Collections, and selecting the hidden collection ends up hitting /organizations/<org_id>/collections/<coll_id>/details, which results in the log message Unauthorized Error: The current user isn't a manager for this collection and the user being logged out.

This seems to be a regression introduced when adding support for the manager user type. I have a PR that should fix this.

@jjlin commented on GitHub: I didn't see any issues with hidden collections being displayed, but going to the `Manage` tab for the org, clicking `Collections`, and selecting the hidden collection ends up hitting `/organizations/<org_id>/collections/<coll_id>/details`, which results in the log message `Unauthorized Error: The current user isn't a manager for this collection` and the user being logged out. This seems to be a regression introduced when adding support for the manager user type. I have a PR that should fix this.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#1512