starred/vaultwarden

Fork 0

mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-03-02 22:57:18 -05:00

Live sync for organization items only working when not using roles / groups #1562

New issue

Closed

opened 2026-02-20 08:10:53 -05:00 by deekerman · 7 comments

deekerman commented

2026-02-20 08:10:53 -05:00

Owner

Originally created by @wucherpfennig on GitHub (Apr 3, 2023).

Subject of the issue

live sync for organization items does not work if you are using roles / groups.
live sync does not work if you are adding members via group to a collection
live sync works only if you are adding a member directly to a collection

Deployment environment

vaultwarden version: 1.28.1-alpine
Install method: docker
Clients used: all (tested: Windows Desktop, Browser, Firefox, Chrome)
Reverse proxy and version: traefik-2.9.9
MySQL/MariaDB or PostgreSQL version: 8.X
Other relevant details: websocket works as without using groups everything runs as expected

Steps to reproduce

Create an organisation
Create a collection
Create a group
Create two test accounts
assign one account to the group (3) and then the group (3) to the collection (2)
assign one account directly to the collection (2)
add / update / delete items in the collection (2)

Result

account from 5: will only see the changes via reload
account from 6: will see the changes immediately

Expected behaviour

Live sync all the items to all the group members not only to the "hardcoded" directly assigned collection members.

Actual behaviour

Changes from organization members (independent whether using groups or not) will be reflected immediately to the organization owner but if the owner / somebody else creates a new entry in the collection this change will only be available after a "hard" reload (ctrl+shift+r).

This issue is resolved by no using groups! By not using them everything works as expected.

BR wucherpfennig

Originally created by @wucherpfennig on GitHub (Apr 3, 2023). ### Subject of the issue * live sync for organization items **does not work** if you are using roles / groups. * live sync **does not work** if you are adding members via group to a collection * live sync **works** only if you are adding a member directly to a collection ### Deployment environment * vaultwarden version: 1.28.1-alpine * Install method: docker * Clients used: all (tested: Windows Desktop, Browser, Firefox, Chrome) * Reverse proxy and version: traefik-2.9.9 * MySQL/MariaDB or PostgreSQL version: 8.X * Other relevant details: websocket works as without using groups everything runs as expected ### Steps to reproduce 1. Create an organisation 2. Create a collection 3. Create a group 4. Create two test accounts 5. assign one account to the group (3) and then the group (3) to the collection (2) 6. assign one account directly to the collection (2) 7. add / update / delete items in the collection (2) **Result** * account from 5: will only see the changes via reload * account from 6: will see the changes immediately ### Expected behaviour Live sync all the items to all the group members not only to the "hardcoded" directly assigned collection members. ### Actual behaviour Changes from organization members (independent whether using groups or not) will be reflected immediately to the organization owner but if the owner / somebody else creates a new entry in the collection this change will only be available after a "hard" reload (ctrl+shift+r). This issue is resolved by no using groups! By not using them everything works as expected. BR wucherpfennig

deekerman

2026-02-20 08:10:53 -05:00

closed this issue
added the
bug

troubleshooting

low priority

help wanted
labels

deekerman commented

2026-02-20 08:10:54 -05:00

Author

Owner

@BlackDex commented on GitHub (Apr 3, 2023):

Thanks for the report.
I want to note that groups is still an experimental feature. But we do need reports like this to make it better.

@BlackDex commented on GitHub (Apr 3, 2023): Thanks for the report. I want to note that groups is still an experimental feature. But we do need reports like this to make it better.

deekerman commented

2026-02-20 08:10:55 -05:00

Author

Owner

@wucherpfennig commented on GitHub (Apr 3, 2023):

We are very much aware of that "experimental" state but to be honest until now everything else works great and it saves us a lot of time managing our accounts and collections. 👍🏻

@wucherpfennig commented on GitHub (Apr 3, 2023): We are very much aware of that "experimental" state but to be honest until now everything else works great and it saves us a lot of time managing our accounts and collections. 👍🏻

deekerman commented

2026-02-20 08:10:55 -05:00

Author

Owner

@BlackDex commented on GitHub (Apr 3, 2023):

Good to hear 😄 . It's probably a query which needs some extra joins (which i do not like)

@BlackDex commented on GitHub (Apr 3, 2023): Good to hear 😄 . It's probably a query which needs some extra joins (which i do not like)

deekerman commented

2026-02-20 08:10:55 -05:00

Author

Owner

@ghunti commented on GitHub (Jul 20, 2023):

I have the same issue running 1.29.0

@ghunti commented on GitHub (Jul 20, 2023): I have the same issue running 1.29.0

deekerman commented

2026-02-20 08:10:55 -05:00

Author

Owner

@BlackDex commented on GitHub (Jul 20, 2023):

I have the same issue running 1.29.0

Which is logical, since the issue is still open ;)

@BlackDex commented on GitHub (Jul 20, 2023): > I have the same issue running 1.29.0 Which is logical, since the issue is still open ;)

deekerman commented

2026-02-20 08:10:55 -05:00

Author

Owner

@xKugeki commented on GitHub (Aug 1, 2023):

Are there any new information about bug fixing this problem ^^?
Or workarounds with groups enabled + Live Sync :)

@xKugeki commented on GitHub (Aug 1, 2023): Are there any new information about bug fixing this problem ^^? Or workarounds with groups enabled + Live Sync :)

deekerman commented

2026-02-20 08:10:55 -05:00

Author

Owner

@BlackDex commented on GitHub (Aug 1, 2023):

Not from my part yet. I have not found the time or will to try and tackle this specific issue.
I have some ideas to try and use sub-select queries to maybe tackle this in a bit nice way instead of creating complex joins.
But not yet started on it. So if somebody else finds this an interesting item to pickup, please do not hesitate, there is a help-wanted label there for a reason ;)

@BlackDex commented on GitHub (Aug 1, 2023): Not from my part yet. I have not found the time or will to try and tackle this specific issue. I have some ideas to try and use sub-select queries to maybe tackle this in a bit nice way instead of creating complex joins. But not yet started on it. So if somebody else finds this an interesting item to pickup, please do not hesitate, there is a `help-wanted` label there for a reason ;)