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

28 lines
708 B
Python
Raw Normal View History

Change Realm defaults to Community defaults. Previously, we set restrict_to_domain and invite_required differently depending on whether we were setting up a community or a corporate realm. Setting restrict_to_domain requires validation on the domain of the user's email, which is messy in the web realm creation flow, since we validate the user's email before knowing whether the user intends to set up a corporate or community realm. The simplest solution is to have the realm creation flow impose as few restrictions as possible (community defaults), and then worry about restrict_to_domain etc. after the user is already in. We set the test suite to explictly use the old defaults, since several of the tests depend on the old defaults. This commit adds a database migration.
2016-10-28 21:43:47 +02:00
from django.db import migrations, models
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
migrations: Refactor the enum type fields. Accessing attributes is the preferred design pattern, as it is more readable.
2020-02-17 17:13:57 +01:00
COMMUNITY = 2
Change Realm defaults to Community defaults. Previously, we set restrict_to_domain and invite_required differently depending on whether we were setting up a community or a corporate realm. Setting restrict_to_domain requires validation on the domain of the user's email, which is messy in the web realm creation flow, since we validate the user's email before knowing whether the user intends to set up a corporate or community realm. The simplest solution is to have the realm creation flow impose as few restrictions as possible (community defaults), and then worry about restrict_to_domain etc. after the user is already in. We set the test suite to explictly use the old defaults, since several of the tests depend on the old defaults. This commit adds a database migration.
2016-10-28 21:43:47 +02:00
class Migration(migrations.Migration):
dependencies = [
('zerver', '0037_disallow_null_string_id'),
]
operations = [
migrations.AlterField(
model_name='realm',
name='invite_required',
field=models.BooleanField(default=True),
),
migrations.AlterField(
model_name='realm',
name='org_type',
migrations: Refactor the enum type fields. Accessing attributes is the preferred design pattern, as it is more readable.
2020-02-17 17:13:57 +01:00
field=models.PositiveSmallIntegerField(default=COMMUNITY),
Change Realm defaults to Community defaults. Previously, we set restrict_to_domain and invite_required differently depending on whether we were setting up a community or a corporate realm. Setting restrict_to_domain requires validation on the domain of the user's email, which is messy in the web realm creation flow, since we validate the user's email before knowing whether the user intends to set up a corporate or community realm. The simplest solution is to have the realm creation flow impose as few restrictions as possible (community defaults), and then worry about restrict_to_domain etc. after the user is already in. We set the test suite to explictly use the old defaults, since several of the tests depend on the old defaults. This commit adds a database migration.
2016-10-28 21:43:47 +02:00
),
migrations.AlterField(
model_name='realm',
name='restricted_to_domain',
field=models.BooleanField(default=False),
),
]