WPB-18190: Add route to delete collaborator from team#4694
WPB-18190: Add route to delete collaborator from team#4694blackheaven merged 50 commits intodevelopfrom
Conversation
There was a problem hiding this comment.
I'm not sure how to handle this one.
I have tried to move services/galley/src/Galley/Effects/ConversationStore.hs in lib/wire-subsystems, but Cassandra queries and many data-types are in Galley.
I'm also not sure how to list the O2O conversations of a (TeamId, UserId).
I would be inclined to create a dedicate effects, with one operation and a Cassandra interpreter, having queries in the same file.
WDYT?
There was a problem hiding this comment.
This one is failing with:
[brig@example.com] E, IO Exception occurred, message=ResponseError {reHost = datacenter1:rack1:127.0.0.1:9042, reTrace = Nothing, reWarn = [], reCause = Invalid "unconfigured table conversation"}, request=abef79a6-8f9f-41b3-b674-036e4216db63
[brig@example.com] E, request=abef79a6-8f9f-41b3-b674-036e4216db63, code=500, label=server-error, "Server Error"
I feel like I'm in another key space, can I have some hints about it?
8e873f3 to
78aea4e
Compare
pcapriotti
left a comment
There was a problem hiding this comment.
Looks good overall, but I'm not sure about the logic for deleting conversations. See comments below.
There was a problem hiding this comment.
I don't think this is enough. This would leave the conversation in the database, as well as member entries. It's probably better to reuse the conversation store here, which already has a deleteConversation method.
There was a problem hiding this comment.
This doesn't look right to me, but maybe I'm not understanding something. In my understanding, we should:
- delete all one2one conversations with unconnected team members
- remove ourselves from team conversations.
The code here seems to only look for team conversations that were created by the collaborator, and then delete them. I can't see anything about one2one conversations. Regardless, I don't think it matters who created the conversation. When a collaboration is ended, the collaborator should simply be kicked from team conversations.
There was a problem hiding this comment.
I have deleteConversation for One2One conversations type, and remove user-conversation relationship otherwise, let me know what you think.
83eb7a1 to
c1f5acf
Compare
|
I cannot reproduce the error, which seems not related to my changes. |
c1f5acf to
0969d6d
Compare
|
@battermann I have made the change to rely on the same mechanisms behind Thanks. |
There was a problem hiding this comment.
I think we should create a few team and 1:1 conversations and verify that the user is removed.
We should also verify that the user still exists and is still member of other non-team conersations etc.
There was a problem hiding this comment.
Sorry, I have missed it:
yes, I would create a couple of conversations, team group conv, 1:1 conv, non-team conv, and then check membership after the collaborator is removed
There was a problem hiding this comment.
TODO: find how to create team and non-team convs
There was a problem hiding this comment.
@battermann I did not managed to create non-team conversation becoming one, but the remaining edge cases are checked let me know what you think.
There was a problem hiding this comment.
I am not sure about the naming convention here. Why the prefix Internal?
There was a problem hiding this comment.
Mainly because we do not check permissions in it, should I drop it?
There was a problem hiding this comment.
Ah got it. It's fine then.
c5e0a60 to
30c92d0
Compare
pcapriotti
left a comment
There was a problem hiding this comment.
I'm still not convinced that the removal logic is correct.
- we shouldn't delete all 1-1 conversations indiscriminately, but just the ones with unconnected team members. I'm thinking of cases where a user A was connected with team member B, then A is added as a collaborator of B's team, then removed. We don't want to delete the conversation between A and B in that case.
- I don't think we should be manually making db queries. That makes it harder to check that we're not breaking any invariants. Instead, we should use internal APIs and/or low-level helper functions that are shared with the rest of the code, even if that makes things less efficient.
There was a problem hiding this comment.
Same issue as in #4708: we shouldn't use IN queries.
There was a problem hiding this comment.
Same here. Instead, I think we should use the existing pagination internal API, like we do when deleting a user.
There was a problem hiding this comment.
dropped, however, I'm not sur what you are referring to, there is nothing more in rmUser.
5eb2959 to
c510050
Compare
741ffd8 to
0ec3937
Compare
services/brig/src/Brig/Team/API.hs
Outdated
| :<|> Named @"get-team-size" (\uid tid -> lift . liftSem $ teamSizePublic uid tid) | ||
| :<|> Named @"accept-team-invitation" (\luid req -> lift $ liftSem $ acceptTeamInvitation luid req.password req.code) | ||
| :<|> Named @"add-team-collaborator" (\zuid tid (NewTeamCollaborator uid perms) -> lift . liftSem $ createTeamCollaborator zuid uid tid perms) | ||
| :<|> Named @"remove-team-collaborator" (\zuid tid uid -> lift . liftSem $ GalleyAPIAccess.removeTeamMember zuid uid tid) |
There was a problem hiding this comment.
We should move this handler to galley, so that we do not need to make an extra unnecessary call from brig to galley.
|
@battermann I have reworked the the design, I still have to rework the tests |
| :<|> Named | ||
| "remove-team-collaborator" | ||
| ( Summary "Remove a collaborator from the team." | ||
| :> From 'V11 |
There was a problem hiding this comment.
updated, thanks.
| | NewTeamCollaborator | ||
| | JoinRegularConversations | ||
| | CreateApp | ||
| | RemoveTeamCollaborator |
There was a problem hiding this comment.
Is this used, I can't find it
There was a problem hiding this comment.
It is in removeTeamCollaborator, the handler.
| defProteus {team = Just team, qualifiedUsers = [alice, bob]} | ||
| >>= getJSON 201 | ||
|
|
||
| withWebSockets [owner, alice] $ \[wsOwner, wsAlice] -> do |
There was a problem hiding this comment.
should the collaborator themselves, also get an event?
| ) | ||
| . (.status) | ||
| uncheckedDeleteTeamMember lusr Nothing tid rusr toNotify | ||
| internalRemoveTeamCollaborator rusr tid |
There was a problem hiding this comment.
should we send the collaborator remove event here?
| | EdConvDelete ConvId | ||
| | EdCollaboratorAdd UserId [CollaboratorPermission] | ||
| | EdAppCreate UserId | ||
| | EdCollaboratorRemove UserId |
There was a problem hiding this comment.
this is not sent, is it?
| EdReasonDeleted | ||
| ) | ||
| def | ||
| case () of |
There was a problem hiding this comment.
this is a funny construct, why not match on the cnvmType value directly?
f7bee64 to
1c458bf
Compare
Co-authored-by: Leif Battermann <leif.battermann@wire.com>
6ab2eaa to
9986c2f
Compare
https://wearezeta.atlassian.net/browse/WPB-18190
Checklist
changelog.dPS: I did not see #4685, sorry