When using the groups-feature on the testing-branch, a "regular" group-member (non-manager) cannot create any entries in a collection, that is given access to via groups.
Deployment environment
Your environment (Generated via diagnostics page)
Vaultwarden version: v1.26.0-d0b53a6a
Web-vault version: v2022.11.2
Running within Docker: true (Base: Debian)
Environment settings overridden: true
Uses a reverse proxy: true
IP Header check: true (X-Real-IP)
Internet access: true
Internet access via a proxy: false
DNS Check: true
Time Check: true
Domain Configuration Check: true
HTTPS Check: true
Database type: PostgreSQL
Database version: PostgreSQL 13.3 on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
Clients used:
Reverse proxy and version:
Other relevant information:
Steps to reproduce
Create an organisation (or use existing)
Add another user "U" (any name is fine) to the organisation (as a regular user)
Create(or use existing) collection "C" (any name is fine)
Create(or use existing) group "G" (any name is fine)
4.1. Give permission of that collection "C" to the group "G"
4.2. Assign the user "U" to the group "G"
4.3. Make sure that the user "U" does not have direct permission on the collection "C". In other words: the permission should be configured via the group only!
Login as user "U"
5.1. Add a new entry to the collection "C"
Expected behavior
The entry should be added to the collection.
Actual behavior
An error toast appears in the top right: "You lack the necessary permissions to perform this action."
Originally created by @olsn on GitHub (Dec 15, 2022).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/2989
### Subject of the issue
When using the groups-feature on the testing-branch, a "regular" group-member (non-manager) cannot create any entries in a collection, that is given access to via groups.
### Deployment environment
### Your environment (Generated via diagnostics page)
* Vaultwarden version: v1.26.0-d0b53a6a
* Web-vault version: v2022.11.2
* Running within Docker: true (Base: Debian)
* Environment settings overridden: true
* Uses a reverse proxy: true
* IP Header check: true (X-Real-IP)
* Internet access: true
* Internet access via a proxy: false
* DNS Check: true
* Time Check: true
* Domain Configuration Check: true
* HTTPS Check: true
* Database type: PostgreSQL
* Database version: PostgreSQL 13.3 on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
* Clients used:
* Reverse proxy and version:
* Other relevant information:
### Steps to reproduce
1. Create an organisation (or use existing)
2. Add another user "U" (any name is fine) to the organisation (as a regular user)
3. Create(or use existing) collection "C" (any name is fine)
4. Create(or use existing) group "G" (any name is fine)
4.1. Give permission of that collection "C" to the group "G"
4.2. Assign the user "U" to the group "G"
4.3. Make sure that the user "U" does **not** have direct permission on the collection "C". In other words: the permission should be configured via the group only!
5. Login as user "U"
5.1. Add a new entry to the collection "C"
### Expected behavior
The entry should be added to the collection.
### Actual behavior
An error toast appears in the top right: "You lack the necessary permissions to perform this action."
GiteaMirror
added the bug label 2026-04-20 13:40:03 -05:00
This indeed is an issue. We see some more issues with groups currently, and probably going to disable groups by default for now until we have worked out all the issues.
You are still free to use it of course, but bugs like this will be in there until we have some time to look at this new feature a bit better.
<!-- gh-comment-id:1353185572 -->
@BlackDex commented on GitHub (Dec 15, 2022):
This indeed is an issue. We see some more issues with groups currently, and probably going to disable groups by default for now until we have worked out all the issues.
You are still free to use it of course, but bugs like this will be in there until we have some time to look at this new feature a bit better.
I have created a PR #2995 which puts this feature behind a flag, and disabled by default.
This features needs some more TLC from devs.
<!-- gh-comment-id:1353359186 -->
@BlackDex commented on GitHub (Dec 15, 2022):
I have created a PR #2995 which puts this feature behind a flag, and disabled by default.
This features needs some more TLC from devs.
Maybe I'm doing something wrong, but I'm encountering the same issue on 1.27 when the user is a manager, not a regular user. Here's my system info:
Your environment (Generated via diagnostics page)
Vaultwarden version: v1.27.0
Web-vault version: v2022.12.0
Running within Docker: true (Base: Debian)
Environment settings overridden: true
Uses a reverse proxy: true
IP Header check: true (X-Real-IP)
Internet access: true
Internet access via a proxy: false
DNS Check: true
Time Check: true
Domain Configuration Check: true
HTTPS Check: true
Database type: SQLite
Database version: 3.39.2
Clients used:
Reverse proxy and version:
Other relevant information:
My user is a manager, has access control set to "access only selected collections" and none of the collections ticked.
The group is is set to "access only selected collections" as well, with one collection ticked, and both access options off.
The collection appears in the users collection list, passwords show up, but new entries can't be added. I'm aware this feature is in beta and the issue is known, but figured I'd report that it apparently also affects the manager role. Maybe someone can confirm if this issue is on the server side, or my side.
<!-- gh-comment-id:1383961984 -->
@bytebone commented on GitHub (Jan 16, 2023):
Maybe I'm doing something wrong, but I'm encountering the same issue on 1.27 when the user is a manager, not a regular user. Here's my system info:
### Your environment (Generated via diagnostics page)
* Vaultwarden version: v1.27.0
* Web-vault version: v2022.12.0
* Running within Docker: true (Base: Debian)
* Environment settings overridden: true
* Uses a reverse proxy: true
* IP Header check: true (X-Real-IP)
* Internet access: true
* Internet access via a proxy: false
* DNS Check: true
* Time Check: true
* Domain Configuration Check: true
* HTTPS Check: true
* Database type: SQLite
* Database version: 3.39.2
* Clients used:
* Reverse proxy and version:
* Other relevant information:
My user is a manager, has access control set to "access only selected collections" and none of the collections ticked.
The group is is set to "access only selected collections" as well, with one collection ticked, and both access options **off**.
The collection appears in the users collection list, passwords show up, but new entries can't be added. I'm aware this feature is in beta and the issue is known, but figured I'd report that it apparently also affects the manager role. Maybe someone can confirm if this issue is on the server side, or my side.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @olsn on GitHub (Dec 15, 2022).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/2989
Subject of the issue
When using the groups-feature on the testing-branch, a "regular" group-member (non-manager) cannot create any entries in a collection, that is given access to via groups.
Deployment environment
Your environment (Generated via diagnostics page)
Steps to reproduce
4.1. Give permission of that collection "C" to the group "G"
4.2. Assign the user "U" to the group "G"
4.3. Make sure that the user "U" does not have direct permission on the collection "C". In other words: the permission should be configured via the group only!
5.1. Add a new entry to the collection "C"
Expected behavior
The entry should be added to the collection.
Actual behavior
An error toast appears in the top right: "You lack the necessary permissions to perform this action."
@BlackDex commented on GitHub (Dec 15, 2022):
This indeed is an issue. We see some more issues with groups currently, and probably going to disable groups by default for now until we have worked out all the issues.
You are still free to use it of course, but bugs like this will be in there until we have some time to look at this new feature a bit better.
@BlackDex commented on GitHub (Dec 15, 2022):
I have created a PR #2995 which puts this feature behind a flag, and disabled by default.
This features needs some more TLC from devs.
@bytebone commented on GitHub (Jan 16, 2023):
Maybe I'm doing something wrong, but I'm encountering the same issue on 1.27 when the user is a manager, not a regular user. Here's my system info:
Your environment (Generated via diagnostics page)
My user is a manager, has access control set to "access only selected collections" and none of the collections ticked.
The group is is set to "access only selected collections" as well, with one collection ticked, and both access options off.
The collection appears in the users collection list, passwords show up, but new entries can't be added. I'm aware this feature is in beta and the issue is known, but figured I'd report that it apparently also affects the manager role. Maybe someone can confirm if this issue is on the server side, or my side.
@BlackDex commented on GitHub (Jan 16, 2023):
This probably is the same issue. Which has not been addressed.