Identify narrows with user IDs and stream IDs, not emails and names #4333
Comments
|
I would like to work on this! |
|
Hi @Ayushdubey86 ! This issue is a pretty complex one, and I'm already working on it. To find good issues to take on, take a look at our "help wanted" label. See also our contribution guidelines, and say hello in #mobile on chat.zulip.org. |
This completes a major objective of the long string of refactoring that appeared in the series of PRs zulip#4330, zulip#4332, zulip#4335, zulip#4339, zulip#4342, then zulip#4346, zulip#4356, zulip#4361, zulip#4364, and most recently zulip#4368. After this change, the portion of zulip#4333 that's about PMs, emails, and user IDs -- aka the portion of zulip#3764 that's about narrows -- is complete. Still open from zulip#4333 is to convert stream and topic narrows from stream names to stream IDs. I'm hopeful that that will be simpler: (a) unlike the situation for PMs, there's just one stream mentioned at a time, so there's no question of sorting, and (b) there isn't the "include self or not" complication that's bedeviled much of our code related to PMs. In other words, stream and topic narrows don't suffer from zulip#4035.
|
Just adding a note that we'll want to open a zulip/zulip issue for doing the cleanup discussed here: |
|
Thanks, Tim!
I was mistaken about this; we actually don't use it, so the |
In the migration tests, it is kind of messy that we have to update a previous migration's test. That happens because we're running all the migrations to completion. As the comment at the "whole sequence" test says about a related point: this is probably not a great design for continuing to add more migrations in this sequence. But pretty soon we're going to cap it off and write future migrations in a new framework, which will come with its own way of writing tests. So for the moment just live with it. Fixes-partly: #4333
This is a major component of both #3764 and #3918. Currently we describe PM narrows (both 1:1 and group) by emails of the people involved, and stream and topic narrows by the stream name (and in the latter case the topic.) We should instead use the numeric user IDs and stream IDs, for all the reasons described in #3764 and #3918.
This has been a stubborn issue to resolve because there are so many places in the code that we create and consume
Narrowobjects, and so many different places the data for them comes from, and all of those need to migrate. I've had several draft branches for doing this, starting with some in 2020-02. The work I'm currently doing on #4035, of which #4332 just now is the latest, will bring it closer by centralizing the fiddly bits in the PM case, and in particular making it so that we always have user IDs on hand at the points where we construct PM narrows.One symptom of this issue is described at #3230. (Though probably a rare one; found internally, and has no user reports.)
The text was updated successfully, but these errors were encountered: