Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zulip/zerver/migrations/0174_userprofile_delivery_e...

33 lines
1.0 KiB
Python
Raw Normal View History

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-05 20:08:30 +02:00
# -*- coding: utf-8 -*-
# Generated by Django 1.11.13 on 2018-07-05 17:57
from __future__ import unicode_literals
from django.db import migrations, models
from django.db.backends.postgresql_psycopg2.schema import DatabaseSchemaEditor
from django.db.migrations.state import StateApps
python: Sort migrations/management command imports with isort. This is a preparatory commit for using isort for sorting all of our imports, merging changes to files where we can easily review the changes as something we're happy with. These are also files with relatively little active development, which means we don't expect much merge conflict risk from these changes.
2020-01-14 21:59:46 +01:00
from django.db.models import F
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-05 20:08:30 +02:00
def copy_email_field(apps: StateApps, schema_editor: DatabaseSchemaEditor) -> None:
UserProfile = apps.get_model('zerver', 'UserProfile')
UserProfile.objects.all().update(delivery_email=F('email'))
class Migration(migrations.Migration):
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 23:09:03 +02:00
atomic = False
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-05 20:08:30 +02:00
dependencies = [
('zerver', '0173_support_seat_based_plans'),
]
operations = [
migrations.AddField(
model_name='userprofile',
name='delivery_email',
field=models.EmailField(db_index=True, default='', max_length=254),
preserve_default=False,
),
migrations.RunPython(copy_email_field,
reverse_code=migrations.RunPython.noop),
]