Description
This is a meta-issue which covers a large number of independent tasks. Filing it in order to have an identifier (ha) we can use to refer to the overall effort.
In general, Zulip originally used a user's email address as the primary way of identifying the user, throughout the API and the client data structures. This isn't good -- among other reasons, because people change their email addresses. So, years ago, we shifted toward using numeric user IDs. This was a slow migration, but the server and the webapp are now pretty far along; just about the whole API can now operate in terms of user IDs.
In the mobile app, though, we still pass around emails to identify users in lots of places. This often complicates the code, as different layers look up the email for a user ID and vice versa in order to communicate with other layers; it also leads to bugs when a user changes their email address. So we should fix it.
In general, this means:
- Almost everywhere that we pass an email in an API request, it should instead be a user ID.
- If the API route doesn't accept user IDs, there should be an issue for that on zulip/zulip and a comment linking to that next to our code that passes an email.
- This requires some care to handle older servers that don't accept user IDs on the given route; see Typing notifications are mistyped, resulting in rejection (for servers < 2.0) #3732.
- Almost everywhere that a React component takes a prop like
email
, it should instead be auserId
.- Possibly everywhere. Anyplace where we have a good reason to take an
email
prop -- other than the boring reason that we haven't gotten around to converting it yet -- there should be a comment explaining why.
- Possibly everywhere. Anyplace where we have a good reason to take an
- Almost everywhere that we have an object or
Map
data structure where the keys are emails, they should instead be user IDs.- The main exception is the data structures, like the one returned by
getAllUsersByEmail
, that we use only within code we haven't converted yet. Once other code is all converted, those should disappear too, or be used only in rare exceptional spots. (E.g., sending email addresses in API requests to older servers.)
- The main exception is the data structures, like the one returned by
Tasks for specific instances of this migration include #3501 and #3525; #3196 was related. There are also a lot of parts of the code where the conversion is straightforward; in those cases we don't need to file specific issues, and can just refer to this one.