Pass in collection ids to notifier when sharing cipher. #1153

Closed
opened 2026-04-06 01:41:18 +02:00 by MrUnknownDE · 0 comments
Owner

Originally created by @kristof-mattei on 4/19/2024

(sorry about hitting publish too soon).

This PR fixes a bug where moving a cipher from a personal vault to an organization does not attach the collection ids of which the cipher is now a member.

The front-end relies on these if the notification type is NotificationType.SyncCipherUpdate (91f1d9fb86/libs/common/src/services/notifications.service.ts (L150)) which in turn controls isEdit in syncUpsertCipher (91f1d9fb86/libs/common/src/vault/services/sync/sync.service.ts (L177)). If isEdit is true (we moved a cipher, we didn't create one) we need the collectionIds otherwise shouldUpdate remains false (91f1d9fb86/libs/common/src/vault/services/sync/sync.service.ts (L213)).

This causes a client on the receiving side to fail to properly update its view, requiring a manual refresh.

Before:

https://github.com/dani-garcia/vaultwarden/assets/864376/d2e0d455-2bd6-476f-823c-b357f0bd2f15

After:

https://github.com/dani-garcia/vaultwarden/assets/864376/8e08a0bd-9ea6-4bda-b1e8-67ab7e68514a

I chose Option<Vec<String>> because that's what the notifier service takes, even though technically we could do Vec<String> but that makes it much uglier for other consumers. Passing in None is much nicer than vec![].

*Originally created by @kristof-mattei on 4/19/2024* (sorry about hitting publish too soon). This PR fixes a bug where moving a cipher from a personal vault to an organization does not attach the collection ids of which the cipher is now a member. The front-end relies on these if the notification type is `NotificationType.SyncCipherUpdate` (https://github.com/bitwarden/clients/blob/91f1d9fb86142805d0774182c3ee6234e13946e3/libs/common/src/services/notifications.service.ts#L150) which in turn controls `isEdit` in `syncUpsertCipher` (https://github.com/bitwarden/clients/blob/91f1d9fb86142805d0774182c3ee6234e13946e3/libs/common/src/vault/services/sync/sync.service.ts#L177). If `isEdit` is `true` (we moved a cipher, we didn't create one) we need the `collectionIds` otherwise `shouldUpdate` remains `false` (https://github.com/bitwarden/clients/blob/91f1d9fb86142805d0774182c3ee6234e13946e3/libs/common/src/vault/services/sync/sync.service.ts#L213). This causes a client on the receiving side to fail to properly update its view, requiring a manual refresh. Before: https://github.com/dani-garcia/vaultwarden/assets/864376/d2e0d455-2bd6-476f-823c-b357f0bd2f15 After: https://github.com/dani-garcia/vaultwarden/assets/864376/8e08a0bd-9ea6-4bda-b1e8-67ab7e68514a I chose `Option<Vec<String>>` because that's what the notifier service takes, even though technically we could do `Vec<String>` but that makes it much uglier for other consumers. Passing in `None` is much nicer than `vec![]`.
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/vaultwarden#1153