This commit includes the following changes:
- Add an administrator setting to customize the Welcome Bot
message when sending an invitation.
- Add an API endpoint to test the customized Welcome Bot message
by sending a copy of the message to the administrator.
Fixes#27663.
Co-authored-by: Akarsh Jain <akarsh.jain.790@gmail.com>
Fixes#20028.
There's no reason to have a special `RealmCreationKey` class - the
`Confirmation` system already does this job.
This is somewhat complicated by the need to write a migration for
`RealmCreationKey`->`Confirmation` for pre-existing, valid objects, to
avoid breaking realm creation links that haven't been used yet.
This commit updates code to require unique names for only
non-archived folders in a realm, which means a folder can
use a name which is being used by an archived folder.
This commit adds a realm setting:
"Require end-to-end encryption for push notification content".
This commit just involves backend & UI changes to add the setting,
the impact of this setting is in the next commit.
Fixes part of #35370.
This commit adds support to send encrypted push notifications
to devices registered to receive encrypted notifications.
URL: `POST /api/v1/remotes/push/e2ee/notify`
payload: `realm_uuid` and `device_id_to_encrypted_data`
The POST request needs to be authenticated with the server’s
API key.
Note: For Zulip Cloud, a background fact about the push bouncer is
that it runs on the same server and database as the main application;
it’s not a separate service. So, as an optimization we directly call
'send_e2ee_push_notifications' function and skip the HTTP request.
APNs apparently treats its tokens case-insensitively; FCM does not.
Adjust the `unique_together` to instead be separate partial
constraints, keyed on the `kind` of the PushDeviceToken.
This commit adds a `PushDevice` model where each row
corresponds to an account on an install of the app
that has attempted to register with the bouncer to
receive mobile push notifications.
This is the core server table storing registrations
that are potentially registered with the mobile push
notifications bouncer service.
This commit updates code to use "\x07" as value for
"subject" field of Message objects for DMs and group
DMs, so that we have a unique value for DMs and group
DMs which cannot be used for channel messages.
This helps in avoiding having an empty string value as
topic for DMs, which is also used for "general chat"
channel messages, as large number of DMs in the realm
resulted in PostgreSQL query planner thinking that there
are too many "general chat" messages and thus generated
bad query plans for operations like fetching
"general chat" messages in a stream or moving messages
to and from "general chat" topic.
This change as done for ArchivedMessage and
ScheduledMessage objects as well.
Note that the clients still get "subject" value as
an empty string "".
This commit also adds tests for checking that "\x07"
cannot be used as topic for channel messages.
Fixes#34360.
This commit adds a new personal setting
`resolved_topic_notice_auto_read_policy` which controls how
resolved-topic notices are marked as read for a user.
Fixes#33599.
This commit:
* Creates a migration to rename any existing Client with
name="populate_db" to "ZulipDataImport".
* Updates populate_db.py to use ZulipDataImport for new
message creation
These changes should make code to identify imported messages
considerably more readable.
Fixes#33909.
This follows our usual backporting scheme, occurring e.g.
in #31468. We make the migration depend on the last migration in 10.x,
and create a merge migration to avoid having multiple leafs.
In #34510 we fixed the underlying bug in the ldap integration, which
would cause users to end up with their system group memberships not
matching their .role value. However, users who may already be in that
state still need to be fixed through a migration. We implement that
here.
There are two things we fix here:
1. Group memberships. The user should have a direct group membership
for the specific system group implied by their .role.
2. We want to also add the missing RealmAuditLog entry.
This just records the time when the user created the
request to schedule a message or set a reminder.
This would be unused but is future-proofing against a world
where we decide to edit the strings or UI to show when you
asked for the thing.
A prep PR to 34308.
Explicitly pass the fields to be updated,
This increases performance but most importantly
prevents overwriting the db-saved value of
"subscriber_count" field (added in an upcoming PR)
with the in-memory default value of 0,
since "subscriber_count" will only be updted
via the db.
Migrate some tests to use do_ functions instead of
direclty modifying the state.
Currently, imported direct messages from third-party exports might have
a non-empty string as their topic name.
This migration updates the topic names for all imported third-party DMs
and GDMs to an empty string if they aren’t already.
Fixes#29466.
Co-authored-by: Pieter CK <pieterceka123@gmail.com>
The Django ORM query would not work correctly for pathological
DirectMessageGroups with no Subscription rows. When the Subquery gave
empty results, the UPDATE would set group_size to null - when the point
of the migration was exactly to make sure this column is always set and
allow making the column non-nullable in 0575.
Such DirectMessageGroups can occur as a result doing .delete() on all
UserProfiles that were in the group - or by doing realm deletion via
either .delete() or `manage.py delete_realm`.
The natural choice for group_size of these objects is 0. The simple SQL
query naturally achieves this result, without needing any special
handling for this case.
This commit adds migration to move messages from "(no topic)"
to the empty string topic.
It'll help in our plan to interpret messages sent to
"(no topic)" as being sent to "".
That interpretation will be particularly helpful for older
clients where sending messages with empty topic input box
currently results in messages being sent to "(no topic)" topic.
In 0680, we moved messages from the "general chat" topic
to the empty string topic. Therefore, we skip moving messages
from "(no topic)" if an empty string topic already exists.
Such cases—where both "(no topic)" and an empty string topic
coexist in a channel—should be rare. The solution is to either
manually rename the "(no topic)" topic or manually move its
messages to the empty string topic.
These extended statistics allow the query planner to know that the
prevalence of empty topics is very different in DMs, as opposed to
channel messages. The `ALTER STATISTICS` adjusts the size of the
"most common value" list -- it must be large enough to include the
empty-topic channel messages to be fully effective. Having this list
be over-large does not carry much risk, however.
The `ANALYZE zerver_message` step may be quite slow.
Indexes on topic ("subject") are polluted by the existence of DMs,
which all have empty topics, and as such skew the statistics greatly.
This is particularly important given the new use of the empty topic
for the "general chat" function -- left as-is, the database makes bad
query plans because it believes the topic is vastly more common than
it actually is.
We move the old indexes to a new name with `_all`, and
recreate (concurrently) the same indexes but with a condition on
is_channel_message. These new indexes are unused at current, until
the query-building logic adds limits on is_channel_message; see the
following commit.
