For get and filter queries of NamedUserGroup, realm_for_sharding
field is used instead of realm field, as directly using
realm_for_sharding field on NamedUserGroup makes the query faster
than using realm present on the base UserGroup table.
Previously, we enqueued events to "missedmessage_mobile_notifications"
even for users who had no registered push devices.
'handle_push_notification' later used to perform the check & skip
if there were no registered devices.
This commit avoids putting such events into the
"missedmessage_mobile_notifications" queue at all. By doing so,
we reduce unnecessary churn.
This avoids a potential unnecessary message.recipient fetch required by
is_stream_message(). is_stream_message() methods precedes the addition
of the denormalized is_channel_message column and is now unnecessary.
In practice, we usually fetch Message objects with `.recipient` already,
so I don't expect any notable performance impact here - but it's still a
useful change to make.
If the client has passed `simplified_presence_events` as true
in the `client_capabilities` parameter of the `POST /register`
request, then the server will send `presence` events with the
`presences` field, which has the user presence data in the
modern API format. When that client capability is false, the
`presence` event will be unchanged and sent with the user
presence data in the legacy format.
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>
The test cases are copied from ReorderCustomProfileFieldTest since we
are imitating the reordering mechanism from custom profile fields to
channel folders.
Previously, when there were two topics -- A and B, and a user
follows topic A, then when messages of topic B are merged into
topic A then topic A loses its follow status.
This is fixed by updating the algorithm for getting the visibility
policy after merge to be followed in the above case.
Fixes#35226
Earlier, editing a message with wildcard mention and removing the
wildcard mention didn't properly remove the corresponding flag for
it in the message object. It was only updating flags when mentions
were present in new message but not the other way around.
This commit fixes this behaviour by removing flags if the new message
removed mention from it.
This commit updates code to send messages to "general chat" topic
if streams used for announcements for "New user signups",
"New created streams", "Moderation requests" and "Zulip updates"
have topics policy set to allow only "general chat" messages.
Welcome Bot should auto-reply to users in 1:1 DMs, including when
the direct message group recipient model is used. This ensures
the bot detects and responds to messages where it is a recipient,
for both PERSONAL and DIRECT_MESSAGE_GROUP recipient types.
Fixes: part of issue #25713.
This commit is a preparatory step for allowing organization owners to
reset user preferences, refactors the `clear_scheduled_emails` function
to support bulk operations.
Previouly, there was no option to play the inline audio files
within the web app without downloading or leaving the browser.
This commit adds option to render inline audio files that use
the syntax ``.
Fixes#27007
This commit adds a feature, wherein when someone moves a user's
message to be the first message in a topic, and the user has the
Automatically follow topics initiated enabled, then the new topic will
also be followed by the user.
Similarly, if the user has Automatically unmute topics initiated
enabled, the moved topic would also be unmuted.
Fixes#28408.
When creating a new organization, the new user default for email
address visibility is now limited to admins for most organization
types. The exceptions are education organizations, which have the
default set to moderators, and business organizations, which have
the default set to all users.
Fixes#34859.
In user signup context, we are okay with there being an existing mirror
dummy user with the matching email - at the end of the signup, that
mirror dummy account will be activated and control of it given to the
user doing this signup.
However, in email change contexts (SCIM API and regular email change
flow), we can't change an account's email address to the address that
already belongs to an existing mirror dummy user.
To avoid subtle bugs like this, we make callers have to explicitly
specify whether existance of mirror dummies with the matching email
address is okay or not.
We obviously shouldn't set such objects to REVOKED as that introduces
misleading information into our data. USED objects cannot be re-used, so
they can stay as they are.
The `acting_user` parameter is added in preparation to make
`do_update_outgoing_webhook_service` log `RealmAuditLog` when updating
bots service. It doesn't have any use as of right now.
This updates `do_update_outgoing_webhook_service` to use
`BotServicesOutgoing` as the schema for the updated service data we send
back to client because it's the schema `bot_data.update` expects.
The function is also refactored to allow updating specific fields of the
Service row instead of requiring all value for the Service fields to be
passed.
This is a prep commit for #34524, it adds another field to the Service
field.
We abstract away "near" vs "with" from the function names and
allow callers to specify whether they want a conversation_link,
ie, use the "with" operator. The default choice is "near".
This commit fixes a flake in `do_delete_messages`, because of
which `test_do_delete_messages_grouping_logic` test occasionally
failed due to nondeterministic ordering of "delete_message" events.
The root cause was that the dictionaries used to group private
and stream messages for deletion (`private_messages_by_recipient`
and `stream_messages_by_topic`) were not sorted before generating
the events. While the `message_ids` within each event were already
sorted, the order of the events themselves could vary based on
the insertion order of the dictionaries, especially when running
tests in different sequences.
We now sort both `private_messages_by_recipient` and
`stream_messages_by_topic` before emitting events, ensuring
consistent ordering.
Sending messages to a deactivated stream is not allowed with
the exception of notices sent in "channel events" topic.
Earlier, notice sent to a deactivated stream when it is
deactivated was working correctly but it was resulting in
an error in the following cases:
* Renaming stream
* Changing stream description
* Changing message retention period
* Changing posting permission
* Changing access permission
This commit makes sure to send notice successfully in those cases.
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.
