github-starred/vaultwarden
2
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-07-17 01:12:27 -05:00
Code Issues 481 Packages Projects Releases 83 Wiki Activity

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

New Issue
Closed
opened 2026-03-07 20:16:59 -06:00 by GiteaMirror · 7 comments
GiteaMirror commented 2026-03-07 20:16:59 -06:00
Owner
Copy Link

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

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
GiteaMirror added the troubleshootingbuglow priorityhelp wanted labels 2026-03-07 20:16:59 -06:00
GiteaMirror commented 2026-03-07 20:17:00 -06:00
Author
Owner
Copy Link

@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.
GiteaMirror commented 2026-03-07 20:17:01 -06:00
Author
Owner
Copy Link

@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. 👍🏻
GiteaMirror commented 2026-03-07 20:17:02 -06:00
Author
Owner
Copy Link

@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)
GiteaMirror commented 2026-03-07 20:17:03 -06:00
Author
Owner
Copy Link

@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
GiteaMirror commented 2026-03-07 20:17:03 -06:00
Author
Owner
Copy Link

@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 ;)
GiteaMirror commented 2026-03-07 20:17:03 -06:00
Author
Owner
Copy Link

@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 :)
GiteaMirror commented 2026-03-07 20:17:04 -06:00
Author
Owner
Copy Link

@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 ;)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
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 Label bug help wanted low priority troubleshooting
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#5200
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?