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...

29 lines
709 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
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
python: Reformat with Black, except quotes. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-02-12 08:19:30 +01:00
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 = [
python: Normalize quotes with Black. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-02-12 08:20:45 +01:00
("zerver", "0037_disallow_null_string_id"),
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
]
operations = [
migrations.AlterField(
python: Normalize quotes with Black. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-02-12 08:20:45 +01:00
model_name="realm",
name="invite_required",
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
field=models.BooleanField(default=True),
),
migrations.AlterField(
python: Normalize quotes with Black. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-02-12 08:20:45 +01:00
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(
python: Normalize quotes with Black. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-02-12 08:20:45 +01:00
model_name="realm",
name="restricted_to_domain",
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
field=models.BooleanField(default=False),
),
]