-
Notifications
You must be signed in to change notification settings - Fork 333
Federation: support conversation access updates #1808
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
4ebea26
to
378019f
Compare
8249bc8
to
edb1772
Compare
84a9aa5
to
fad0975
Compare
2ed2132
to
3151928
Compare
modelConversationAccessDataEvent :: Doc.Model | ||
modelConversationAccessDataEvent = Doc.defineModel "ConversationAccessDataEvent" $ do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was renamed by mistake.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in a0cf82c.
Doc.description "conversation access update event" | ||
Doc.property "data" (Doc.ref modelConversationAccessUpdate) $ Doc.description "conversation access data" | ||
Doc.property "data" (Doc.ref modelConversationAccessData) $ Doc.description "conversation access data" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was fine.
Also changed the name of `ConversationAccessUpdate` to `ConversationAccessData`, since it is going to be used to keep track of the current access and role, instead of just updates.
3151928
to
a0cf82c
Compare
This generalises the on-conversation-updated RPC to support notifications of conversation access updates, by adding a new constructor to the corresponding "action" type.
Note: An access update can potentially trigger member deletion. The previous code was performing the access update on the database, sending the corresponding notification, then deleting members, in that order. That meant that a failure in deleting members would result in the whole request failure, even though the access update was performed successfully. So now members are deleted asynchronously in a separate thread, similarly to how notifications to bots are sent.
This is part of https://wearezeta.atlassian.net/browse/SQCORE-885 (federated conversation metadata updates).
Checklist
changelog.d
.