[GH-ISSUE #457] Add entry to read-only collection: No error message #278

New issue

Closed

opened 2026-03-03 01:27:33 +03:00 by kerem · 3 comments

kerem commented

2026-03-03 01:27:33 +03:00

Owner

Originally created by @SebastianS90 on GitHub (Apr 13, 2019).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/457

When I have read-only access to a collection and attempt to edit an entry, then I get an error message on save (which is fine).
But when I add an entry then it reports that it has been saved successfully, even in the log it says Outcome: Success for the /api/ciphers/create query. After reloading the vault, the entry disappears.

Server: mprasil/bitwarden:1.8.0-alpine

PS: Thank you so much for this amazing server implementation!

Originally created by @SebastianS90 on GitHub (Apr 13, 2019). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/457 When I have read-only access to a collection and attempt to edit an entry, then I get an error message on save (which is fine). But when I add an entry then it reports that it has been saved successfully, even in the log it says `Outcome: Success` for the `/api/ciphers/create` query. After reloading the vault, the entry disappears. Server: `mprasil/bitwarden:1.8.0-alpine` PS: Thank you so much for this amazing server implementation!

kerem

2026-03-03 01:27:33 +03:00

closed this issue
added the
troubleshooting
label

kerem commented

2026-03-03 01:27:34 +03:00

Author

Owner

@SebastianS90 commented on GitHub (Apr 13, 2019):

The new entries are saved, but not in any collection and therefore the user cannot see it. You might still want to fail the save action in that case (user has read-only access) to avoid confusion.

@SebastianS90 commented on GitHub (Apr 13, 2019): The new entries are saved, but not in any collection and therefore the user cannot see it. You might still want to fail the save action in that case (user has read-only access) to avoid confusion.

kerem commented

2026-03-03 01:27:34 +03:00

Author

Owner

@janost commented on GitHub (Apr 14, 2019):

I'm not able to reproduce this issue.

As a user who has RO access to the collection, attempting to add an item into the collection results in these log entries:

[2019-04-14 22:34:37][rocket::rocket][INFO] POST /api/ciphers/create application/json; charset=utf-8:
[2019-04-14 22:34:37][_][INFO] Matched: POST /api/ciphers/create (post_ciphers_create)
[2019-04-14 22:34:37][bitwarden_rs::error][ERROR] No rights to modify the collection. No rights to modify the collection
[2019-04-14 22:34:37][_][INFO] Outcome: Success
[2019-04-14 22:34:37][_][INFO] Response succeeded.

The web vault displays an error message ("No rights to modify the collection") and the item doesn't seem to be saved.

Can you please try the latest master build and if the problem still persists, can you please post reproduction steps?

@janost commented on GitHub (Apr 14, 2019): I'm not able to reproduce this issue. As a user who has RO access to the collection, attempting to add an item into the collection results in these log entries: ``` [2019-04-14 22:34:37][rocket::rocket][INFO] POST /api/ciphers/create application/json; charset=utf-8: [2019-04-14 22:34:37][_][INFO] Matched: POST /api/ciphers/create (post_ciphers_create) [2019-04-14 22:34:37][bitwarden_rs::error][ERROR] No rights to modify the collection. No rights to modify the collection [2019-04-14 22:34:37][_][INFO] Outcome: Success [2019-04-14 22:34:37][_][INFO] Response succeeded. ``` The web vault displays an error message ("No rights to modify the collection") and the item doesn't seem to be saved. Can you please try the latest master build and if the problem still persists, can you please post reproduction steps?

kerem commented

2026-03-03 01:27:34 +03:00

Author

Owner

@SebastianS90 commented on GitHub (Apr 15, 2019):

I cannot reproduce it with master anymore. So it probably has been fixed somewhere between the 1.8.0 release and current master.

@SebastianS90 commented on GitHub (Apr 15, 2019): I cannot reproduce it with master anymore. So it probably has been fixed somewhere between the `1.8.0` release and current master.