The grouping logic in `do_delete_messages` calls
`message.is_stream_message()` in a loop, which needs to access
message.recipient. This is obviously super inefficient if .recipient
hasn't been prefetched for the message objects.
`delete_in_topic` is the only function that calls `do_delete_messages`
with many messages, so this is the only spot we need to fix, to address
the immediate bug.
Of course a better improvement would be to fix `do_delete_messages` to
do something smarter than naively accessing message.recipient in a loop.
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>
We do not test relative links here since relative links were only
used in the old help pages. We should probably remove the logic
for relative links after we have done the official cutover to the
starlight help center: #35654.
We are going to move the help center to starlight soon and the tests
won't be able to access that help center until we solve things in a
followup issue. We move some of the urls being tested from /help to /api
to not loose coverage on those tests.
The test cases are copied from ReorderCustomProfileFieldTest since we
are imitating the reordering mechanism from custom profile fields to
channel folders.
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.
Clears up some naming confusion - `REALM_CREATION_LINK_VALIDITY_DAYS` is
a setting which describes the validaty period of RealmCreationKey, not
of Confirmation with REALM_CREATION type. Now that the latter is called
NEW_REALM_USER_REGISTRATION, there should be no confusion about this.
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 is only `text/plain`, currently. In such cases where the
client-provided content-type also does not specify a `charset`, we use
`chardet` to make a guess, and store that guess to provide later when
serving the content. The detection is done in a streaming fashion,
and thus should not require re-downloading the full content.
This commit adds an error code to make it easier for clients
to identify when push device registration is rejected due to
server not being configured to use push notification service.
Fixes part of 35368.
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.
Uses the approach done for email change confirmations in #34980 to avoid
triggering a reactivation via just a GET request. Instead, the GET
should return a page which will trigger the browser to then POST the key
to the endpoint.
This commit addresses the issue where the topic highlighting
in search results was offset by one character when an
apostrophe was present. The problem stemmed from the disparity
in HTML escaping generated by the function `func.escape_html` which
is used to obtain `topic_matches` differs from the escaping performed
by the function `django.utils.html.escape` for apostrophes (').
func.escape_html | django.utils.html.escape
-----------------+--------------------------
' | '
To fix this SQL query is changed to return the HTML-escaped
topic name generated by the function `func.escape_html`.
Fixes: #25633.
Co-authored-by: Pieter CK <pieterceka123@gmail.com>
This commit is a preparatory step for allowing organization owners to
reset user preferences, refactors the `clear_scheduled_emails` function
to support bulk operations.
In 40956ae4c5 we implemented group sync
via SAML during sign in and sign up. The sign up implementation used a
session variable group_memberships_sync_map to plumb through the sync
information to the registration codepath, to execute group sync after
user creation.
We can use a more robust approach instead, and just amend groups on the
`PreregistrationUser` object that's going to be used for registration.
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.
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.
