msglist: Don't assume people with the same name are the same. #4304
Conversation
This file contains hidden or 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
chrisbobbe
reviewed
Nov 12, 2020
src/message/renderMessages.js
Outdated
| @@ -31,11 +31,11 @@ export default ( | |||
| data: [], | |||
| }); | |||
| } | |||
|
|
|||
| // TODO(#3674): Use sender_id, not sender_email. Needs adding | |||
There was a problem hiding this comment.
I think you mean #3764?
|
LGTM except for two tiny comments, above—I think those are just typos in an issue number. |
Ha, indeed I do. Thanks for the catch! I'll edit that and merge. |
Discovered this bug by reading the code, while studying this function to understand zulip#4301 (for 5b52614.) Kind of hard to see how this way of writing it could ever have seemed like the right thing to do; it's been this way essentially forever, since f1b10f4 in 2016. Sadly we can't use the sender's actual, permanent, numeric user ID here, because outbox messages (values of type Outbox) don't have a sender_id. We'll fix that next. For now, using the email suffices to fix this bug, and leaves this code no worse than a lot of the rest of our code. Fixes: zulip#4303
This will allow us to stop using sender_email to identify users in places like renderMessages.
gnprice
force-pushed
the
pr-msglist-name-vs-id
branch
from
e4c1326 to
a1fad7c
Compare
gnprice
added a commit
that referenced
this pull request
Oct 18, 2021
We started supplying this property in 0c251bf / #5000. That went out to users a few weeks ago, in v17.171 which rolled out 2021-09-23, so by this point the bulk of our users have upgraded to that version. Now we mark the property as required, and drop any old outbox messages that lack it in the unlikely case that there are any. This completes #3998 because we've already done the same thing for `sender_id`, in a1fad7c / #4304 and then 60847c9 / #4667. Fixes: #3998
gnprice
added a commit
to gnprice/zulip-mobile
that referenced
this pull request
Oct 19, 2021
We started supplying this property in 0c251bf / zulip#5000. That went out to users a few weeks ago, in v17.171 which rolled out 2021-09-23, so by this point the bulk of our users have upgraded to that version. Now we mark the property as required, and drop any old outbox messages that lack it in the unlikely case that there are any. This completes zulip#3998 because we've already done the same thing for `sender_id`, in a1fad7c / zulip#4304 and then 60847c9 / zulip#4667. Fixes: zulip#3998
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.
Fixes: #4303
Sadly we can't use the sender's actual, permanent, numeric user ID here, because outbox messages (values of type Outbox) don't have a sender_id. For now, using the email suffices to fix this bug, and leaves this code no worse than a lot of the rest of our code.
We also add a sender_id property to Outbox... but don't yet switch to using it, because existing outbox messages, if there were any just before the user upgrades to a release with this change, won't yet have it. Once such a release has been out for a few weeks, we can make the property required and have a migration just drop any values lacking it. There's a TODO comment marking this as one of the many sites of #3674.