This excludes the legacy webhook from the
"realm_incoming_webhook_bots" object as those do not have the same URL
format as modern webhook integrations.
We should search for what the user asked us to search for.
CZO conversation:
https://chat.zulip.org/#narrow/stream/101-design/topic/search.20buddy.20list.20for.20self/near/1630454
This commit also stops the user from being at the top of
the search list, so that the search list is fully
alphabetical (though still sorted by online status).
We switch to not having the user at the top of the list
only when there's search text in the search bar, otherwise
there'd be a visual jump that would happen just by opening
the search bar. There's almost always visual change when
entering text into the search input field, so that seems
like the time to change the sorting.
This commit fixes the alignment of account-alert-notification-banner
by using a new classname 'account-alert-notification' for this specific
banner, removed the default margin-top and margin-left from this banner
which is set to all other banners, and Aligned the banner with
vertical-align property set to middle.
To left-align this specific banner when the email is long enough
to wrap to the next line removed the margin-left and used a new
classname 'account-settings-heading' for the accounts heading,
and gave a margin-right of 10px to ensure that the notice banner and
the heading have enough space between them, when the email is short.
If the email is long enough to wrap to multiple lines, then the gap
between the email input field and the banner is too low. To adjust
this, set the margin-bottom to 10px.
This commit fixes the issue where, if the content inside the alert
notification banner is long enough, it will wrap inside the alert
banner.
To prevent the email from spilling over in the notice,added the
'overflow-wrap' property set to 'anywhere'.
Fixes: #23653
This change adds support for importing guest users from a Mattermost
export file into Zulip. The function now checks the user's teams and
roles to determine whether the user is a guest on the team, and sets
the user's role accordingly. This ensures that the imported user data
includes the correct role for each user.
Fixes#23720.
This fixes a regression introduced in
9954db4b59, where the realm's default
language would be ignored for users created via API/LDAP/SAML,
resulting in all such users having English as their default language.
The API/LDAP/SAML account creation code paths don't have a request,
and thus cannot pull default language from the user's browser.
We have the `realm.default_language` field intended for this use case,
but it was not being passed through the system.
Rather than pass `realm.default_language` through from each caller, we
make the low-level user creation code set this field, as that seems
more robust to the creation of future callers.
Making request a mandatory kwarg avoids confusion about the meaning of
parameters, especially with `request` acquiring the ability to be None
in the upcoming next commit.
Letting the clock tick without a reason introduces the
possibility of nondeterministic test failures depending on the execution
time. The default value when not specified is tick=True, which makes it
easy to miss.
The rule doesn't prohibit setting tick=True, as perhaps there will be
tests wanting to use that feature on purpose, but such a test should
explicitly set it to make the intent clear.
None of these tests seem to want to have tick=True, which is the
default. Letting the clock tick without a reason introduces the
possibility of nondeterministic test failures depending on the execution
time.
Earlier, followed topics in muted streams were not listed in
the 'Recent conversations' table when 'Include muted' filter is
unchecked.
They should be listed as we currently list unmuted topics.
The "test_filter_all" includes tests for muted and not muted topics,
but the 'is_spectator' field is set to 'true'.
Logically, it is incorrect because a topic can't have a
visibility policy set in spectator view.
This commit fixes the incorrect behavior and adds a separate test
for the case 'is_spectator=true'.
The issue was introduced in d0a697f.
Refactor tools/lib/provision_inner to conditionally write activation commands to user's bash profile based on the host machine type. Automatic activation now skipped for native linux containers.
Fixes#15029
If you focus on inbox-header name by right arrow then down and then
left, it will focus on unread count instead of ellipsis icon.
Hard to explain how this fixes the bug here, next commit adds
explanatory comments to the function.
This reverts b8581e2895. The mobile
client on Android parses this field using:
```kotlin
timeMs = data.require("time").parseLong("time") * 1000
```
This throws an error if value is not `long` (i.e. an integer),
resulting in dropped notifications on Android from servers which had
deployed b8581e2895.
Switch back to sending an integer, but keep the behaviour from
fd6091ad17 where we send the timestamp in the payload of both
Android and Apple push notifications.
Rather than fetch all UserMessage rows for all streams, and subtract
those out in Python-space from the list of all Message rows the user
may have received -- do this via a "NOT EXISTS" subquery. This is
much better indexed (performing in fractions of milliseconds rather
than hundreds), and also consumes much less memory.
Adds support for bulk-adjusting a single user's membership in multiple
user groups in a single transaction in the low-level actions
functions, for future use by work on #9957.
This commit resolves an issue where the edit button was not visible
during message hover for new messages. The problem occurred when a
message was sent after the hover event, resulting in the hovered
message being a local copy with the `locally_echoed` attribute set
to true. This caused the `is_message_editable_ignoring_permissions`
function to return false, subsequently causing `is_content_editable`
to return false as well. As a result, the `is_content_editable`
argument was false, leading to the edit button not being displayed.
The issue was caused due `$current_message_hover` being set to the
locally echoed version of `$message_row`. When the message was
successfully sent and the message was rerendered, the `message_hover`
function was called again on the properly sent message row.
However, the conditional check `($current_message_hover &&
rows.id($current_message_hover) === id)` returned true because
`$current_message_hover`, set to the locally echoed version, had the
same ID as the actual `$message_row`. Consequently, this condition
returned true at the start of the `message_hover` function,
preventing further execution of message_hover function and,
consequently, the updating of hover buttons.
To address this, an `else if` condition was introduced to check if
the message is locally echoed. If true, the function is terminated
to prevent `$current_message_hover` from being set to the locally
echoed version of `$message_row` until the message is sent correctly.
Once the message is sent correctly, the `message_hover` function is
executed again, setting `$current_message_row` to the properly sent
version of `$message_row`, and resulting in updating of hover buttons.
Fixes#25312