[WPB-6144] Prevent MLS one-to-one messaging for a blocking user #3889
Conversation
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
mdimjasevic
force-pushed
the
wpb-6144/1-to-1-messaging-by-blocked-user
branch
from
f83d610 to
0d0d823
Compare
zebot
added
the
ok-to-test
mdimjasevic
force-pushed
the
wpb-6144/1-to-1-messaging-by-blocked-user
branch
2 times, most recently
from
34ad309 to
117e81b
Compare
This reverts commit c4af150.
mdimjasevic
force-pushed
the
wpb-6144/1-to-1-messaging-by-blocked-user
branch
from
a23c84c to
84e531c
Compare
What is left to do is to make this check work for an MLS 1-1 conv that can be remote
akshaymankar
force-pushed
the
wpb-6144/1-to-1-messaging-by-blocked-user
branch
2 times, most recently
from
0e7cade to
eac9f2a
Compare
Brig can determine this ID based on protocol of the conversation or read it from the DB. Inventing this in galley causes more trouble for having two One2One convs for proteus and mls.
akshaymankar
force-pushed
the
wpb-6144/1-to-1-messaging-by-blocked-user
branch
from
eac9f2a to
5820f58
Compare
…ssaging-by-blocked-user
…ssaging-by-blocked-user
mdimjasevic
changed the title
mdimjasevic
added a commit
that referenced
this pull request
Feb 26, 2024
* Test: no MLS 1-to-1 when a connection is blocked * Test: a test with expected behavior after blocking the connection * Check if sending a msg to 1-to-1 and not connected * Add a changelog * WIP: Debugging a test failure * Update the confirming test * Revert "Check if sending a msg to 1-to-1 and not connected" This reverts commit c4af150. * WIP: generalise the Update.blockConv handler * Connections: Also block MLS one2one conv when blocking conn * Test: Parameterise over One2OneScenario * Add the missing connection ID in an internal endpoint * Wrap a function comment for readability * Introduce a Galley internal endpoint: blocking a qualified conversation * WIP: Check if an MLS 1-1 conv exists before blocking What is left to do is to make this check work for an MLS 1-1 conv that can be remote * Make upsertOne2OneConv always take a Conv ID Brig can determine this ID based on protocol of the conversation or read it from the DB. Inventing this in galley causes more trouble for having two One2One convs for proteus and mls. * WIP: Remove user from 1:1 MLS conv when they block someone * WIP: Remove mls clients on connection block * fixup! WIP: Remove mls clients on connection block * Make sure 1-1 conv is established before updating * Finalise the bug-confirming test * Remove debugging output from application code * Fix a changelog * Remove redundant constraints * Properly check if an MLS 1-1 conversation exists before blocking it * Remove more of unused code * Remove an unused connection ID in an internal Galley endpoint for blocking a conv --------- Co-authored-by: Akshay Mankar <akshay@wire.com>
This was referenced Feb 26, 2024
mdimjasevic
added a commit
that referenced
this pull request
Mar 5, 2024
* Test: no MLS 1-to-1 when a connection is blocked * Test: a test with expected behavior after blocking the connection * Check if sending a msg to 1-to-1 and not connected * Add a changelog * WIP: Debugging a test failure * Update the confirming test * Revert "Check if sending a msg to 1-to-1 and not connected" This reverts commit c4af150. * WIP: generalise the Update.blockConv handler * Connections: Also block MLS one2one conv when blocking conn * Test: Parameterise over One2OneScenario * Add the missing connection ID in an internal endpoint * Wrap a function comment for readability * Introduce a Galley internal endpoint: blocking a qualified conversation * WIP: Check if an MLS 1-1 conv exists before blocking What is left to do is to make this check work for an MLS 1-1 conv that can be remote * Make upsertOne2OneConv always take a Conv ID Brig can determine this ID based on protocol of the conversation or read it from the DB. Inventing this in galley causes more trouble for having two One2One convs for proteus and mls. * WIP: Remove user from 1:1 MLS conv when they block someone * WIP: Remove mls clients on connection block * fixup! WIP: Remove mls clients on connection block * Make sure 1-1 conv is established before updating * Finalise the bug-confirming test * Remove debugging output from application code * Fix a changelog * Remove redundant constraints * Properly check if an MLS 1-1 conversation exists before blocking it * Remove more of unused code * Remove an unused connection ID in an internal Galley endpoint for blocking a conv --------- Co-authored-by: Akshay Mankar <akshay@wire.com>
2 tasks
echoes-hq
bot
added
the
echoes: unplanned
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
If a user blocked another user, the blocking user would still get messages from the blocked user via the MLS one-to-one conversation. This PR fixes the bug.
Tracked by https://wearezeta.atlassian.net/browse/WPB-6144.
Checklist
changelog.d