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.
Currently we have 2 implementations of `config_options`:
- It's used for generating optional webhook URL parameters. These
settings also come with custom UI in the "Generate integration URL"
modal.
- In `/bots` API, it's used as schema for the bots `BotConfigData`. Each
type of bots have different ways of defining their `BotConfigData`
fields. Currently, only embedded bots use `BotConfigData`, and only the
incoming webhooks use `config_options` to configure a bot's
`BotConfigData`; thus, the `config_options` remain unused.
To avoid confusion as to which implementation of `config_options` is
used by an integration, this separates the first use case -- to generate
optional webhook URL -- to a new field called `url_options`. Thus, the
`config_options` field is reserved only for the second use case.
This changelog for feature 318 was added in this commit:
d1ff871523. The changelog stated that it
added a new field called `config_options` to the
`realm__incoming_webhook_bots` field, but in reality, the it renamed an
existing field called `config`.
This fixes the changelog for feature 318 and its changes note in the API
documentation to correctly describe the change.
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.
Having a logger object will be helpful in the upcoming commit to pass as
argument to sync_groups. We use the root logger here (sticking to
original behavior) rather than setting up `getLogger(__name__)` to avoid
breaking a large number of tests which assert logs content - as there
doesn't seem to be any major upside to using a separate logger for this
file.
This commit extracts the method which handles both relative
URLs starting with `/user_uploads` and `user_uploads`,
converting the latter into former, and attaching the path_id
to it.
This is a preparatory commit to #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.
The payload might contain colons and commas within keys and
values entered by the user. Simply splitting the fields using
", " is therefore unreliable and can lead to incorrect parsing.
Hence, this commit updates the logic for splitting fields in
the pretty data of the Jotform payload.
Fixes#32461.
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.
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.
The get_object_from_key call should be included in the transaction - we
shouldn't modify the object if the rest of the function fails to
actually confirm the email change (e.g. due to IntegrityError occurring).
This commit is a preparatory step for allowing organization owners to
reset user preferences, defines a set of sensitive user settings
that will be protected from resets by organization owners.
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.
In the `zulip.yaml` file, the commit
54b5182 - user_groups: Add API support to reactivate a user group
was merged without updating the feature level to the correct format.
This commit fixes that feature level.
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 are adding video support to the function in upcoming commits and we
need to rename the function for that to be more generic.
We've also added a proper return type in the name of DropboxMediaInfo
TypedDict for the `dropbox_media` function.
We currently don't use either of those operators in email
topic links, which breaks the links on topic moves.
Quoting Tim for choosing `near` vs `with`:
"I guess for each case we should decide if we want /near/ links
to /with/ links. We likely want /with/ in some cases, to make
sure we land in the right conversation but not forcing the scroll
position to be on that particular message, which /near/ does."
"I feel like email notifications might want /near/ if the trigger
is a mention or something else that is specific to the message,
rather than the conversation, but probably /with/ otherwise."
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.
