zulip

Commit Graph

Author	SHA1	Message	Date
Tim Abbott	510afd0c93	migrations: Disable atomic for delivery_email migration. I'm not sure theoretically why this should be required only for some installations, but these articles all suggest the root problem is doing these two migrations together atomically (creating the field and setting a value for it), so the right answer is to declare the migration as not atomic: https://stackoverflow.com/questions/12838111/django-db-migrations-cannot-alter-table-because-it-has-pending-trigger-events https://confluence.atlassian.com/confkb/upgrade-failed-with-the-error-message-error-cannot-alter-table-content-because-it-has-pending-trigger-events-747606853.html	2018-09-28 14:14:20 -07:00
Joshua Pan	533eccd655	models: Create delivery_email field in userprofile. This commit creates a new field called delivery_email. For now, it is exactly the same as email upon user profile creation and should stay that way even when email is changed, and is used only for sending outgoing email from Zulip. The purpose of this field is to support an upcoming option where the existing `email` field in Zulip becomes effectively the user's "display email" address, as part of making it possible for users actual email addresses (that can receive email, stored in the delivery_email field) to not be available to other non-administrator users in the organization. Because the `email` field is used in numerous places in display code, in the API, and in database queries, the shortest path to implementing this "private email" feature is to keep "email" as-is in those parts of the codebase, and just set the existing "email" ("display email") model field to be something generated like "username@zulip.example.com" for display purposes. Eventually, we'll want to do further refactoring, either in the form of having both `display_email` and `delivery_email` as fields, or renaming "email" to "username".	2018-07-12 12:30:20 +05:30

Author

SHA1

Message

Date

Tim Abbott

510afd0c93

migrations: Disable atomic for delivery_email migration.

I'm not sure theoretically why this should be required only for some
installations, but these articles all suggest the root problem is
doing these two migrations together atomically (creating the field and
setting a value for it), so the right answer is to declare the
migration as not atomic:

https://stackoverflow.com/questions/12838111/django-db-migrations-cannot-alter-table-because-it-has-pending-trigger-events
https://confluence.atlassian.com/confkb/upgrade-failed-with-the-error-message-error-cannot-alter-table-content-because-it-has-pending-trigger-events-747606853.html

2018-09-28 14:14:20 -07:00

Joshua Pan

533eccd655

models: Create delivery_email field in userprofile.

This commit creates a new field called delivery_email. For now, it is
exactly the same as email upon user profile creation and should stay
that way even when email is changed, and is used only for sending
outgoing email from Zulip.

The purpose of this field is to support an upcoming option where the
existing `email` field in Zulip becomes effectively the user's
"display email" address, as part of making it possible for users
actual email addresses (that can receive email, stored in the
delivery_email field) to not be available to other non-administrator
users in the organization.

Because the `email` field is used in numerous places in display code,
in the API, and in database queries, the shortest path to implementing
this "private email" feature is to keep "email" as-is in those parts
of the codebase, and just set the existing "email" ("display email")
model field to be something generated like
"username@zulip.example.com" for display purposes.

Eventually, we'll want to do further refactoring, either in the form
of having both `display_email` and `delivery_email` as fields, or
renaming "email" to "username".

2018-07-12 12:30:20 +05:30

2 Commits