models: Rename zerver/models.py to zerver/models/__init__.py.

Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit is contained in:
Anders Kaseorg 2023-12-05 10:29:58 -08:00 committed by Tim Abbott
parent 9d11f2c8fc
commit e601d0ae7c
20 changed files with 31 additions and 31 deletions

View File

@ -47,7 +47,7 @@ the development environment][authentication-dev-server].
- The Python queue workers will also automatically restart when you
save changes, as long as they haven't crashed (which can happen if
they reloaded into a version with a syntax error).
- If you change the database schema (`zerver/models.py`), you'll need
- If you change the database schema (`zerver/models/*.py`), you'll need
to use the [Django migrations
process](../subsystems/schema-migrations.md); see also the [new
feature tutorial][new-feature-tutorial] for an example.

View File

@ -17,9 +17,9 @@ paths will be familiar to Django developers.
[Django routes file](https://docs.djangoproject.com/en/3.2/topics/http/urls/).
Defines which URLs are handled by which view functions or templates.
- `zerver/models.py` Main
- `zerver/models/*.py`
[Django models](https://docs.djangoproject.com/en/3.2/topics/db/models/)
file. Defines Zulip's database tables.
files. Defines Zulip's database tables.
- `zerver/lib/*.py` Most library code.

View File

@ -365,7 +365,7 @@ You can look at the [full list of fields][models-py] in the Zulip user
model; search for `class UserProfile`, but the above should cover all
the fields that would be useful to sync from your LDAP databases.
[models-py]: https://github.com/zulip/zulip/blob/main/zerver/models.py
[models-py]: https://github.com/zulip/zulip/blob/main/zerver/models/__init__.py
[django-auth-booleans]: https://django-auth-ldap.readthedocs.io/en/latest/users.html#easy-attributes
### Multiple LDAP searches

View File

@ -95,7 +95,7 @@ is already a function in `zerver.actions` with a name like
`do_change_full_name` that updates that field and notifies clients
correctly.
For convenience, Zulip automatically imports `zerver/models.py`
For convenience, Zulip automatically imports `zerver.models`
into every management shell; if you need to
access other functions, you'll need to import them yourself.

View File

@ -131,7 +131,7 @@ you configure some code to run every time Django does something (for
`post_save`, right after any write to the database using Django's
`.save()`).
There's a handful of lines in `zerver/models.py` like these that
There's a handful of lines in `zerver/models/*.py` like these that
configure this:
```python

View File

@ -9,9 +9,9 @@ This page documents some important issues related to writing schema
migrations.
- If your database migration is just to reflect new fields in
`models.py`, you'll typically want to just:
`models/*.py`, you'll typically want to just:
- Rebase your branch before you start (this may save work later).
- Update the model class definitions in `zerver/models.py`.
- Update the model class definitions in `zerver/models/*.py`.
- Run `./manage.py makemigrations` to generate a migration file
- Rename the migration file to have a descriptive name if Django
generated used a date-based name like `0089_auto_20170710_1353.py`
@ -33,7 +33,7 @@ migrations.
- If your migrations were automatically generated using
`manage.py makemigrations`, a good option is to just remove your
migration and rerun the command after rebasing. Remember to
`git rebase` to do this in the the commit that changed `models.py`
`git rebase` to do this in the the commit that changed `models/*.py`
if you have a multi-commit branch.
- If you wrote code as part of preparing your migrations, or prefer
this workflow, you can use run `./tools/renumber-migrations`,

View File

@ -37,7 +37,7 @@ On a high level the typing indicators system works like this:
Note that there is a user-level privacy setting to disable sending
typing notifications that a client should check when implementing
the "writing user" protocol below. See `send_private_typing_notifications`
in the `UserBaseSettings` model in `zerver/models.py` and in the
in the `UserBaseSettings` model in `zerver/models/__init__.py` and in the
`user_settings` object in the `POST /register` response.
## Writing user

View File

@ -32,7 +32,7 @@ because it takes a long time. Instead, your edit/refresh cycle will
typically involve running subsets of the tests with commands like these:
```bash
./tools/lint zerver/models.py # Lint the file you just changed
./tools/lint zerver/models/__init__.py # Lint the file you just changed
./tools/test-backend zerver.tests.test_markdown.MarkdownTest.test_inline_youtube
./tools/test-backend MarkdownTest # Run `test-backend --help` for more options
./tools/test-js-with-node util
@ -60,7 +60,7 @@ eventually work with, each with its own page detailing how it works:
Additionally, Zulip also has about a dozen smaller tests suites:
- `tools/test-migrations`: Checks whether the `zerver/migrations`
migration content the models defined in `zerver/models.py`. See our
migration content the models defined in `zerver/models/*.py`. See our
[schema migration documentation](../subsystems/schema-migrations.md)
for details on how to do database migrations correctly.
- `tools/test-documentation`: Checks for broken links in this

View File

@ -35,7 +35,7 @@ organization in Zulip). The following files are involved in the process:
**Backend**
- `zerver/models.py`: Defines the database model.
- `zerver/models/__init__.py`: Defines the database model.
- `zerver/views/realm.py`: The view function that implements the API endpoint
for editing realm objects.
- `zerver/actions/realm_settings.py`: Contains code for updating and interacting with the database.
@ -73,7 +73,7 @@ organization in Zulip). The following files are involved in the process:
### Adding a field to the database
**Update the model:** The server accesses the underlying database in
`zerver/models.py`. Add a new field in the appropriate class.
`zerver/models/__init__.py`. Add a new field in the appropriate class.
**Create and run the migration:** To create and apply a migration, run the
following commands:
@ -185,10 +185,10 @@ task of requiring messages to have a topic, you can [view this commit](https://g
First, update the database and model to store the new setting. Add a new
boolean field, `mandatory_topics`, to the Realm model in
`zerver/models.py`.
`zerver/models/__init__.py`.
```diff
# zerver/models.py
# zerver/models/__init__.py
class Realm(models.Model):
# ...
@ -205,7 +205,7 @@ is the field's type. Add the new field to the `property_types`
dictionary.
```diff
# zerver/models.py
# zerver/models/__init__.py
class Realm(models.Model)
# ...

View File

@ -409,7 +409,7 @@ python_rules = RuleList(
},
{
"pattern": r": *(?!Optional)[^\n ].*= models[.].*null=True",
"include_only": {"zerver/models.py"},
"include_only": {"zerver/models/"},
"description": "Model variable with null=true not annotated as Optional.",
"good_lines": [
"desc: Optional[Text] = models.TextField(null=True)",
@ -425,7 +425,7 @@ python_rules = RuleList(
{
"pattern": r": *Optional.*= models[.].*\)",
"exclude_pattern": "null=True",
"include_only": {"zerver/models.py"},
"include_only": {"zerver/models/"},
"description": "Model variable annotated with Optional but variable does not have null=true.",
"good_lines": [
"desc: Optional[Text] = models.TextField(null=True)",

View File

@ -88,7 +88,7 @@ if __name__ == "__main__":
time.sleep(1.3)
print("Attempting to modify a file")
os.utime("zerver/models.py")
os.utime("zerver/models/__init__.py")
failed = check_worker_launch(run_dev)
run_dev.send_signal(signal.SIGINT)

View File

@ -1006,7 +1006,7 @@ export const stream_privacy_policy_values = {
export const stream_post_policy_values = {
// These strings should match the strings in the
// Stream.POST_POLICIES object in zerver/models.py.
// Stream.POST_POLICIES object in zerver/models/__init__.py.
everyone: {
code: StreamPostPolicy.EVERYONE,
description: $t({defaultMessage: "Everyone"}),

View File

@ -10,7 +10,7 @@ const bot_data = zrequire("bot_data");
const people = zrequire("people");
// Bot types and service bot types can be found
// in zerver/models.py - UserProfile Class or
// in zerver/models/__init__.py - UserProfile Class or
// zever/openapi/zulip.yaml
const me = {

View File

@ -182,7 +182,7 @@ def convert_channel_data(
# should be allowed to post in the converted Zulip stream.
# For more details: https://zulip.com/help/stream-sending-policy
#
# See `Stream` model in `zerver/models.py` to know about what each
# See `Stream` model in `zerver/models/__init__.py` to know about what each
# number represent.
stream_post_policy = 4 if channel_dict.get("ro", False) else 1
@ -886,7 +886,7 @@ def map_receiver_id_to_recipient_id(
user_id_to_recipient_id[recipient["type_id"]] = recipient["id"]
# This is inspired by get_huddle_hash from zerver/models.py. It
# This is inspired by get_huddle_hash from zerver/models/__init__.py. It
# expects strings identifying Rocket.Chat users, like
# `LdBZ7kPxtKESyHPEe`, not integer IDs.
#

View File

@ -554,7 +554,7 @@ def changed(update_fields: Optional[Sequence[str]], fields: List[str]) -> bool:
return any(f in update_fields_set for f in fields)
# Called by models.py to flush the user_profile cache whenever we save
# Called by models/__init__.py to flush the user_profile cache whenever we save
# a user_profile object
def flush_user_profile(
*,
@ -591,7 +591,7 @@ def flush_muting_users_cache(*, instance: "MutedUser", **kwargs: object) -> None
cache_delete(get_muting_users_cache_key(mute_object.muted_user_id))
# Called by models.py to flush various caches whenever we save
# Called by models/__init__.py to flush various caches whenever we save
# a Realm object. The main tricky thing here is that Realm info is
# generally cached indirectly through user_profile objects.
def flush_realm(
@ -639,7 +639,7 @@ def realm_text_description_cache_key(realm: "Realm") -> str:
return f"realm_text_description:{realm.string_id}"
# Called by models.py to flush the stream cache whenever we save a stream
# Called by models/__init__.py to flush the stream cache whenever we save a stream
# object.
def flush_stream(
*,

View File

@ -453,7 +453,7 @@ def fetch_initial_state_data(
assert spectator_requested_language is not None
# When UserProfile=None, we want to serve the values for various
# settings as the defaults. Instead of copying the default values
# from models.py here, we access these default values from a
# from models/__init__.py here, we access these default values from a
# temporary UserProfile object that will not be saved to the database.
#
# We also can set various fields to avoid duplicating code

View File

@ -307,7 +307,7 @@ DATE_FIELDS: Dict[TableName, List[Field]] = {
def sanity_check_output(data: TableData) -> None:
# First, we verify that the export tool has a declared
# configuration for every table declared in the `models.py` files.
# configuration for every table declared in the `models` modules.
target_models = [
*apps.get_app_config("analytics").get_models(include_auto_created=True),
*apps.get_app_config("django_otp").get_models(include_auto_created=True),

View File

@ -31,7 +31,7 @@ def update_realmauditlog_values(apps: StateApps, schema_editor: BaseDatabaseSche
}
"""
RealmAuditLog = apps.get_model("zerver", "RealmAuditLog")
# Constants from models.py
# Constants from models/__init__.py
USER_DEFAULT_SENDING_STREAM_CHANGED = 129
USER_DEFAULT_REGISTER_STREAM_CHANGED = 130
USER_DEFAULT_ALL_PUBLIC_STREAMS_CHANGED = 131

View File

@ -6,7 +6,7 @@ from django.db.migrations.state import StateApps
from django.db.models import F, Func, JSONField, TextField, Value
from django.db.models.functions import Cast
# ScheduledMessage.type for onboarding emails from zerver/models.py
# ScheduledMessage.type for onboarding emails from zerver/models/__init__.py
WELCOME = 1