This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Add module API callbacks for adding and deleting local 3PID associations #15044
Merged
Merged
Changes from 2 commits
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
92f46e4
Add module API callbacks for adding and deleting local 3PID associations
anoadragon453 dc8bbe8
Poke Synapse modules when adding or removing a 3PID to a user's account
anoadragon453 3326a66
Remove bound 3pids separately from locally associated 3pids
anoadragon453 195f08c
Delete now unused user_delete_threepids storage method
anoadragon453 2688e5b
Deprecate `on_threepid_bind`
anoadragon453 ee8d1ca
Add documentation for new module api callback methods
anoadragon453 72a9c79
Add a couple unit tests
anoadragon453 312da2d
changelog
anoadragon453 a52fbcc
Move methods to after 3pid add/remove has successfully occurred
anoadragon453 fd26b16
Update references for v1.78 -> v1.79 for this feature. Fix upgrade notes
anoadragon453 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
I'm curious on whether people think this level of caution is necessary?
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.
I find it unintuitive that we trigger the event prior to performing the action.
The only reason I'd expect this would be if we were offering the modules the ability to cancel the event — however this does not seem to be the case.
As it stands, I'd likely prefer to trigger the events after the action has been performed instead, to avoid this 'takeback' situation.
If we are intending to let modules block the association, then we should probably support that here and now.
In my experience with other systems, though, there are usually multiple phases that an event listener can register themselves to an event for: at a minimum, before and after. (with the event only being cancellable before). Maybe we make that explicit with two different API callbacks (or two different phases) — it sounds awkward but then having no way to subscribe to events that are definitely going to happen is also awkward.
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.
I did intend to leave the door open to allowing modules to block the action, and I'm not opposed to adding it now. I only avoided doing so to save time, and don't consider it a breaking change to do so.
Having module callbacks that allow for both before and after an action sound reasonable. In the use case this is intended for (automatically binding 3pids to a company's Sydent instance), subscribing to a post-action callback does sound best (and delivers the guarantees we want without having to do an extra callback in case of a database exception. The module would just accept that if they were going for the pre-action callback.
I think I'm going to update this PR to only include the post-action callback (and leave the name as-is, as it sounds post-action-y already...). A future PR is welcome to add a
can_add_user_third_party_identifier
or somesuch that allows for blocking.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.
Done in a52fbcc.