mirror of
https://github.com/zulip/zulip.git
synced 2025-11-04 05:53:43 +00:00
e39e04c3ce
Note that we use the DjangoJSONEncoder so that we have builtin support for parsing Decimal and datetime. During this intermediate state, the migration that creates extra_data_json field has been run. We prepare for running the backfilling migration that populates extra_data_json from extra_data. This change implements double-write, which is important to keep the state of extra data consistent. For most extra_data usage, this is handled by the overriden `save` method on `AbstractRealmAuditLog`, where we either generates extra_data_json using orjson.loads or ast.literal_eval. While backfilling ensures that old realm audit log entries have extra_data_json populated, double-write ensures that any new entries generated will also have extra_data_json set. So that we can then safely rename extra_data_json to extra_data while ensuring the non-nullable invariant. For completeness, we additionally set RealmAuditLog.NEW_VALUE for the USER_FULL_NAME_CHANGED event. This cannot be handled with the overridden `save`. This addresses: https://github.com/zulip/zulip/pull/23116#discussion_r1040277795 Note that extra_data_json at this point is not used yet. So the test cases do not need to switch to testing extra_data_json. This is later done after we rename extra_data_json to extra_data. Double-write for the remote server audit logs is special, because we only get the dumped bytes from an external source. Luckily, none of the payload carries extra_data that is not generated using orjson.dumps for audit logs of event types in SYNC_BILLING_EVENTS. This can be verified by looking at: `git grep -A 6 -E "event_type=.*(USER_CREATED|USER_ACTIVATED|USER_DEACTIVATED|USER_REACTIVATED|USER_ROLE_CHANGED|REALM_DEACTIVATED|REALM_REACTIVATED)"` Therefore, we just need to populate extra_data_json doing an orjson.loads call after a None-check. Co-authored-by: Zixuan James Li <p359101898@gmail.com>
52 lines
2.0 KiB
Python
52 lines
2.0 KiB
Python
import os
|
|
|
|
ZULIP_VERSION = "8.0-dev+git"
|
|
|
|
# Add information on number of commits and commit hash to version, if available
|
|
zulip_git_version_file = os.path.join(
|
|
os.path.dirname(os.path.abspath(__file__)), "zulip-git-version"
|
|
)
|
|
lines = [ZULIP_VERSION, ""]
|
|
if os.path.exists(zulip_git_version_file):
|
|
with open(zulip_git_version_file) as f:
|
|
lines = [*f, "", ""]
|
|
ZULIP_VERSION = lines.pop(0).strip()
|
|
ZULIP_MERGE_BASE = lines.pop(0).strip()
|
|
|
|
LATEST_MAJOR_VERSION = "7.0"
|
|
LATEST_RELEASE_VERSION = "7.0"
|
|
LATEST_RELEASE_ANNOUNCEMENT = "https://blog.zulip.com/2023/05/31/zulip-7-0-released/"
|
|
|
|
# Versions of the desktop app below DESKTOP_MINIMUM_VERSION will be
|
|
# prevented from connecting to the Zulip server. Versions above
|
|
# DESKTOP_MINIMUM_VERSION but below DESKTOP_WARNING_VERSION will have
|
|
# a banner at the top of the page asking the user to upgrade.
|
|
DESKTOP_MINIMUM_VERSION = "5.4.3"
|
|
DESKTOP_WARNING_VERSION = "5.9.3"
|
|
|
|
# Bump the API_FEATURE_LEVEL whenever an API change is made
|
|
# that clients might want to condition on. If we forget at
|
|
# the time we make the change, then bump it later as soon
|
|
# as we notice; clients using API_FEATURE_LEVEL will just not
|
|
# use the new feature/API until the bump.
|
|
#
|
|
# Changes should be accompanied by documentation explaining what the
|
|
# new level means in api_docs/changelog.md, as well as "**Changes**"
|
|
# entries in the endpoint's documentation in `zulip.yaml`.
|
|
API_FEATURE_LEVEL = 185
|
|
|
|
# Bump the minor PROVISION_VERSION to indicate that folks should provision
|
|
# only when going from an old version of the code to a newer version. Bump
|
|
# the major version to indicate that folks should provision in both
|
|
# directions.
|
|
|
|
# Typically,
|
|
# * adding a dependency only requires a minor version bump;
|
|
# * removing a dependency requires a major version bump;
|
|
# * upgrading a dependency requires a major version bump, unless the
|
|
# upgraded dependency is backwards compatible with all of our
|
|
# historical commits sharing the same major version, in which case a
|
|
# minor version bump suffices.
|
|
|
|
PROVISION_VERSION = (243, 1)
|