Group members cannot add new entries to collection on testing-branch #5074

New Issue

Closed

opened 2026-03-07 20:12:03 -06:00 by GiteaMirror · 4 comments

GiteaMirror commented 2026-03-07 20:12:03 -06:00

Owner

Copy Link

Copy Source

Originally created by @olsn on GitHub (Dec 15, 2022).

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

Originally created by @olsn on GitHub (Dec 15, 2022). ### 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-03-07 20:12:03 -06:00

GiteaMirror closed this issue 2026-03-07 20:12:04 -06:00

GiteaMirror commented 2026-03-07 20:12:05 -06:00

Author

Owner

Copy Link

Copy Source

@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): 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.

GiteaMirror commented 2026-03-07 20:12:05 -06:00

Author

Owner

Copy Link

Copy Source

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

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

GiteaMirror commented 2026-03-07 20:12:06 -06:00

Author

Owner

Copy Link

Copy Source

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

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

GiteaMirror commented 2026-03-07 20:12:07 -06:00

Author

Owner

Copy Link

Copy Source

@BlackDex commented on GitHub (Jan 16, 2023):

This probably is the same issue. Which has not been addressed.

@BlackDex commented on GitHub (Jan 16, 2023): This probably is the same issue. Which has not been addressed.

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

v2-registration

revert-7033-patch-1

cached-config-operations

test_dylint

1.37.2

1.37.1

1.37.0

1.36.0

1.35.8

1.35.7

1.35.6

1.35.5

1.35.4

1.35.3

1.35.2

1.35.1

1.35.0

1.34.3

1.34.2

1.34.1

1.34.0

1.33.2

1.33.1

1.33.0

1.32.7

1.32.6

1.32.5

1.32.4

1.32.3

1.32.2

1.32.1

1.32.0

1.31.0

1.30.5

1.30.4

1.30.3

1.30.2

1.30.1

1.30.0

1.29.2

1.29.1

1.29.0

1.28.1

1.28.0

1.27.0

1.26.0

1.25.2

1.25.1

1.25.0

1.24.0

1.23.1

1.23.0

1.22.2

1.22.1

1.22.0

1.21.0

1.20.0

1.19.0

1.18.0

1.17.0

1.16.3

1.16.2

1.16.1

1.16.0

1.15.1

1.15.0

1.14.2

1.14.1

1.14

1.13.1

1.13.0

1.12.0

1.11.0

1.10.0

1.9.1

1.9.0

1.8.0

1.7.0

1.6.1

1.6.0

1.5.0

1.4.0

1.3.0

1.2.0

1.1.0

1.0.0

0.13.0

0.12.0

0.11.0

0.10.0

0.9.0

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 labels bug

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

GiteaMirror ninjasurge (Kaehlen Rog)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#5074