Skip to content

Convert from emails to user IDs to identify users #3764

Open
@gnprice

Description

@gnprice

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.
  • Almost everywhere that a React component takes a prop like email, it should instead be a userId.
    • 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.
  • 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.)

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions