introduced useCanCreateReactionFromMessage function to reaction message utils. useCanCreateReactionFromMessage does several checks if the user can send a reaction message and depending on the result of those checks will display the react option to the message tooltip. The function checks if the message has been realized (only realized messages have an id), it also checks if the reaction message creator is currently is not blocked by the other target message creator, and it also checks if the reaction message creator has permission to voice in the thread
Details
Please watch the demo videos to see the changes i made (in the middle of the demo, there is some hangtime where I am waiting for simulator to reconnect, feel free to fast forward through that part):
Demos to show scenario where a blocked/blocker pair of users is in a group chat:
Dan's (blocker) POV:
Ryan's (blocked) POV:
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Accepting because the code looks ok
native/chat/reaction-message-utils.js | ||
---|---|---|
94 | We can return a relationship to make this more efficient | |
102–104 | Are we sure that we want to block reactions depending on the relationship? I guess in personal chats it makes sense, but I'm not sure about the public ones. @ashoat do you have an opinion on this? Regardless, we have to make sure that this is consistent with server and web logic. |
Back to you with questions
native/chat/reaction-message-utils.js | ||
---|---|---|
102–104 | Hmm... I'm also curious about how we normally treat a scenario where a blocked/blocker pair of users is in a group chat. @ginsu, two questions for you about that scenario:
Good reminder!! |
native/chat/reaction-message-utils.js | ||
---|---|---|
102–104 | Updated the test plan to have a demo to show this scenario but the TLDR is this:
I tried making the logic for the react tooltip option consistent with what the thread tooltip option has, but let me know if we should be doing something else! |
Cool!! Please make sure privacy/blocking logic is consistent across web/native/keyserver
Found an inconsistency in the privacy/blocking logic in the keyserver and updated D5749 to resolve the inconsistency