-
-
Notifications
You must be signed in to change notification settings - Fork 657
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Self-PM appears in other PM conversations #3324
Comments
Is that a bug though? This is how that works in the web app. |
@borisyankov By "all private narrow" , I doesn't mean "All private message". (editing title to |
Remove `normalizedRecipients === ownEmail` condition, as it is not taking `narrow` in consideration. For self message, `display_recipient` will only consist of `ownEmail`. Thus for calling `isMessageInNarrow` with self message and any private narrow will return `true`. So remove this redundant consition. Fixes: zulip#3324
Remove `normalizedRecipients === ownEmail` condition, as it is not taking `narrow` in consideration. For self message, `display_recipient` will only consist of `ownEmail`. Thus for calling `isMessageInNarrow` with self message and any private narrow was returning `true` (because of `normalizedRecipients === ownEmail`). So remove this condition. Also improve `normalizedNarrow`, so that it consist of only unique values. Now this change will take care of logic which was intended to be taken by previous condition (which got removed, by this commi). Fixes: zulip#3324
Remove `normalizedRecipients === ownEmail` condition, as it is not taking `narrow` in consideration. For self message, `display_recipient` will only consist of `ownEmail`. Thus for calling `isMessageInNarrow` with self message and any private narrow was returning `true` (because of `normalizedRecipients === ownEmail`). So remove this condition. Also improve `normalizedNarrow`, so that it consist of only unique values. Now this change will take care of logic which was intended to be taken by `normalizedRecipients === ownEmail` (which is getting removed, by this commit). Fixes: zulip#3324
Thanks @jainkuniya ! Following up on my comments on #3328, here's what I think would make a good fix for this bug:
|
We had a hilarious bug: if you've already visited some group PM conversation (so that we're following it in `state.narrows`), and then you send yourself a 1:1 PM -- either from some other client, or from this same client -- then the 1:1 will appear to show up in that group conversation. This doesn't affect what messages exist on the server, or what messages anyone else sees. And it can only happen with a message you yourself sent, because it's limited to self-PMs. Still -- it could potentially *look* to you like something quite awkward had happened! Which would, itself, be awkward. The root of the bug is a funny `normalizedRecipients === ownEmail` case in the `isMessageInNarrow` function. That, in turn, seems to be there (it was added in d8faae9, which introduced this bug) to try to correct for where we add `ownEmail` to the list of emails on the line before... which in turn is to try to correct for how in many places we leave out the self-user from describing certain PM narrows. We can fix the bug by consistently using that latter normalization, quirky though it is, within that function. The email list representing a group PM narrow should already be normalized in that way, leaving out the self user; and the old code here was already relying on that. Fixes: zulip#3324
FTR, although #3328 refers to a "regression in Before that point, the code had the opposite bug on self-1:1 messages: they didn't appear even in their own conversation narrow. That commit aimed to fix that, and introduced the puzzling |
We had a hilarious bug: if you've already visited some group PM conversation (so that we're following it in `state.narrows`), and then you send yourself a 1:1 PM -- either from some other client, or from this same client -- then the 1:1 will appear to show up in that group conversation. This doesn't affect what messages exist on the server, or what messages anyone else sees. And it can only happen with a message you yourself sent, because it's limited to self-PMs. Still -- it could potentially *look* to you like something quite awkward had happened! Which would, itself, be awkward. The root of the bug is a funny `normalizedRecipients === ownEmail` case in the `isMessageInNarrow` function. That, in turn, seems to be there (it was added in d8faae9, which introduced this bug) to try to correct for where we add `ownEmail` to the list of emails on the line before... which in turn is to try to correct for how in many places we leave out the self-user from describing certain PM narrows. We can fix the bug by consistently using that latter normalization, quirky though it is, within that function. The email list representing a group PM narrow should already be normalized in that way, leaving out the self user; and the old code here was already relying on that. Fixes: zulip#3324
Steps to reproduce.
newer
caughtup
for that narrow become true.Observation
The message which we posted in step two (to self) is also visible in other narrow (which we picked in step 1,3)
Restart the app, all works fine.
Issue is why message got added to list of other narrow?
Because there is an issue in our
matchRecipients
ofisMessageInNarrow
innarrow.js
.As for all PM narrow,
normalizedRecipients === ownEmail
is true for self message.Because in this condition we are not taking care of
narrow
, it just compare recipient in message andownEmail
.@zulipbot claim
Will send a PR soon for this.
The text was updated successfully, but these errors were encountered: