This renames WebhookConfigOption's "description" field to "label". That
name is consistent with how config_data is declared on the events and
API level, it's also a more accurate description of how the field is
used in the web client, as the UI label element for the config_options.
Adds support for syncing group memberships for a user when logging in
via SAML. The list of group memberships is passed by the IdP in the
zulip_groups SAML attribute in the SAMLResponse.
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.
Set organization type as business when making realms for tests,
and get newly created users with delivery email.
Prep for changes to the default email visibility setting for new
realms based on organization type.
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.
Just like with signup confirmation links, we shouldn't trigger email
change based on a GET to the confirmation URL - POST should be required.
So upon GET of the confirmation link, we serve a form which will
immediately be POSTed by JS code to finalize the email change.
This commit adds option in personal settings to allow
navigation of channel links in left sidebar to the top
unread topic in that channel.
In cases of no unread messages in unmuted topics of the channel,
it falls back to the top topic of channel.
Fixes#35066
This refactors out a function to encode the user ids into URL compatible
format. Previously we use the "-pm" decorator to encode user ids for
group direct messages. That decoration tag is not valid, so this also
updates some existing test cases.
Previously we use `hash_util_encode` to encode channel and topic names
to be URL compatible. This uses the more capable `encode_hash_component`
from the recently added `topic_link_utils.py` module. It also moves the
function to `url_encoding.py`
Previously, when a topic is mentioned, the server generated a
permalink using the earliest accessible message of the topic.
This commit updates it to rather use the latest message of the
topic.
Otherwise, this fails on `match.group(1)` as there is no match group.
The server would ideally respond with a 521 or 556 code[^1] on initial
connection, but aiosmtpd does not provide that option.
[^1]: https://www.rfc-editor.org/rfc/rfc7504
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".
When a user was joining via a multi-use invitation link, using one of
the social auth methods (e.g. Login with Google), the intended group
memberships configured on the multi-use invite would be ignored.
When a user is added to a channel, we send
the user that was added a Notification Bot
DMs to let them know about it.
In this commit, we add an option for whether or not
this message is sent.
If more than 100 users are added at once, we
do not send notification bot DMs since it would
be a performance-costly operation.
We also send this threshold value of 100 in the
initial state data to the clients.
Fixes part of #31189
The URL structure for a shared link has changed since this function was
returned and this commit makes sure our code is in compliance with that
structure.
The concept of an album doesn't exist anymore and folders exist in-lieu
of that.
For dropbox links that are folders on non-image files, we show previews
same as any other link previews. It is not possible to get information
about the shared link except whether it is a file or folder. So for
title and description for that linked preview, we use `Dropbox file` or
`Dropbox folder` respectively.
Earlier, we were just having raw=1 as the query param to get the image
file if required, but now for every dropbox sharing link, preserving
query params is important (otherwise we get a 404), this commit makes
changes to address that.
For /sc/ links, it is not possible to generate them anymore (afaik), but
it is possible to view those existing links, so we support that link but
treat it as a folder instead.
You can check
https://www.dropboxforum.com/discussions/101001012/shared-link--scl-to-s/689070/replies/695266
for URL structure info.
We have used inline ignore for codespell since fo can be a valid
misspell of `of` and we don't want to ignore that.
https://chat.zulip.org/#narrow/channel/9-issues/topic/.F0.9F.93.82.20message_inline_ref.20dropbox.20links
Co-authored-by: Tim Abbott <tabbott@zulip.com>
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.
To maintain API compatibility during and after the migration to use
DirectMessageGroup for 1:1 messages, we need to build the existing
report message format for 1:1 DMs using DirectMessageGroup.
To maintain API compatibility during migration to DirectMessageGroup
for 1:1 DMs, generate notification payloads for such messages in the
same format as those sent to a Personal recipient.
Fixes: part of issue #25713.
This commit adds a test for the grouping logic of the
`do_delete_messages` function, which now groups public and private
messages based on their streams and topics.
This refactor updates `do_delete_messages` to categorize messages by
recipient and topic using a `defaultdict`. Messages are grouped into
batches where each batch corresponds to a unique recipient and topic
combination. For each group, a separate delete event is created and
processed, ensuring compliance with API requirements that mandate one
event per topic.
Co-authored-by: Mateusz Mandera <mateusz.mandera@zulip.com>
