Next

Summary

Reported by Ubertesters.

Steps to reproduce

1. In messenger open a chat and choose block.
2. Close the chat window.
3. Open chat window again.

Platform information

Laptop windows 10, Chrome

Username: yahya94

What is the current bug behavior?

1. Second party is not marked as blocked.
2. User is able to block second party again.
3. Second party is not receiving the messages.
4. User is unable to unblock second party.

What is the expected correct behavior?

1. Second party should be marked as blocked.
2. User should not be able to block second party again.
3. User should not be able to send messages.
4. User should be able to unblock Second party.

Relevant logs and/or screenshots

https://dashboard.ubertesters.com/uploads/8463/11810/issues/64/153839/deeshanib%20_%20Minds%20(1).mp4

Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

added 1 - High P - Messenger T - Bug labels

Can we get usernames between all interacted accounts on all reports?

@JakePassi ^

assigned to @benhayward.ben

changed weight to 2

changed milestone to %sprint: Subscribers

added S - Backlog label

@yahya94 and @PEDROTM

added S - InProgress label and removed S - Backlog label

added S - Review label

added S - Follow Up label and removed S - Review label

Dug into this a bit more and it seems that the problem is that when the conversation is loaded, the blocked status is incorrect. Prior to the image below I started a conversation between 2 browsers. I tested that the messages could be sent and then blocked my secondary account. Looking at the image below, (1) shows the response from the conversation endpoint on load. (2) shows the result of trying to send a message to my primary account.

I need to see if somebody can check on their systems that this is not an issue with my local setup, as I find it strange. Looking at the PHP, This value is gotten from the ACL, which I am sceptical is really is at fault.

added S - Backlog label and removed S - InProgress label

added S - InProgress label and removed S - Backlog label

removed S - InProgress label

@markeharding

Could you replicate the issue on production?

@markeharding Yep, this bug does appear from my perspective (or did when checked) happen on production.

What is the status here?

changed milestone to %sprint: Funny Frog

Will take another look at this this week as my domain knowledge is better now. If I cannot come to a solution in a timely manner I'll hand it off to a more senior developer.

added S - InProgress label and removed S - Follow Up label

added S - Backlog label and removed S - InProgress label

added S - InProgress label and removed S - Backlog label

changed weight to 4

added S - Backlog label and removed S - InProgress label

added S - InProgress label and removed S - Backlog label

I'm unable to see any errors in php-fpm, upon blocking a user, going to investigate why that is in the engine.

Update on that: Can't see anything of issue, and looking at Git Blame it's been a while since those changes were made. Noticed that the engine is storing the block correctly locally as after blocking I cannot access the users profile - the front-end must be getting incorrect data or interpreting it wrongly.

Further update: The banned status is returned incorrectly from the conversations endpoint. Looking at the endpoint we see

if (!Security\ACL::_()->interact(Core\Session::getLoggedInUser(), $participant['guid'])) {
                        $blocked = true;
                        break;
}

Given this, I believe the issue to be in, as it appears to be returning incorrectly for the above conditional https://gitlab.com/benhayward.ben/engine/blame/master/Core/Security/ACL.php

changed milestone to %sprint: Funny Frog

changed weight to 4

moved from front#383 (closed)

mentioned in merge request !185