A user who was no longer subscribed to a private stream kept their
UserMessage row for a message sent while they were in it; this is
expected. However, they _also_ kept that row even if the message was
moved to a different private stream that they were also not subscribed
to. This violates the invariant that users without subscriptions
never have UserMessage rows.
This `if new_stream is not None` block was improperly indented,
causing it to only run if the propagation mode was not `change_one`.
Since the block controlled creation and deletion of UserMessage rows,
this led to messages being improperly still visible to members of the
old stream if they were being moved from public to private streams.
Clients also failed to receive `delete_message` events, so the
messages remained visible in their feeds until they reloaded the
application.
Verified using the original test plan detailed in #18124, checking that the output
is similar, and error handling is correct if the virtualenv is not available.
Fixes#18124.
TypeScript does not check that these annotations are consistent with
the given selector strings. We need to ensure that ourselves for
runtime safety.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This fixes a bug where alert words that are contained in another alert
word would have only the smaller alert word highlighted.
Note that it does not handle weirder cases, like "one two" and "two
three" being alert words; "two three" will always be highlighted, and
not "one"; this is probably fine in practice.
Fixes: #28415
Co-Authored-By: danieldotcomcoder <daniel_shdeed@hotmail.com>
This only defaults to on for local-disk backups, since they are more
disk-size-sensitive, and local accesses are quite cheap compared to
loading multiple incremental backups from S3.
We don't want to show one-time modals introducing 'Inbox' and
'Recent conversations' views to existing users.
When a user views a modal, we mark it as read by storing a row
in the 'OnboardingStep' model. Once marked as read, the user will
no longer see the modal.
This commit adds a migration to create
two rows per user (mark them as read) in OnboardingStep model.
To improve onboarding experience, this commit adds a
one-time modal which introduces the recent conversations view.
Users see this one-time modal on visiting the recent
conversations view.
Fixes#29073.
To improve onboarding experience, this commit adds
a one-time modal which introduces the inbox view.
Users see this one-time modal on visiting the inbox view.
Fixes part of #29073.
When a customer with plan's status 'DOWNGRADE_AT_END_OF_FREE_TRIAL'
visits /billing page on the free-trial end date before the invoice
cron runs, the 'make_end_of_cycle_updates_if_needed' downgrades the
plan.
Earlier, when such a customer visited /billing page in this time window
it resulted in an assertion error.
This commit fixes the incorrect behaviour by redirecting to '/plans'
page in such cases.
We redesign the message history modal to make it look similar to the
drafts and scheduled messages, using the shared styling/rendering
logic for that those existing elements to have a less goofy widget.
Fixes#28695.
Fix a bug where the tooltip for the scroll
to bottom button would remain visible after the
button disapeared, if the user was hovering over
the button as it was dissapearing, without moving
their mouse. Now, the tooltip dissapears when
the button finishes the visibility transition.
Fixes#28656
While they might be useful, it create a potential for elements
that we want to display on wide widths for a setting like
hide user list but was bugged due to a css class like this.
Earlier, the Shift + M shortcut only functioned in messages to
mute/unmute topics in the messages section.
This commit enables the Shift + M shortcut to work in recent
conversations and the inbox. It achieves this by utilizing the
existing function toggle_topic_visibility_policy in user_topics_ui.
The focused row message of the recent_view_ui is passed to mute/unmute the
selected topic in the recent_view_ui, and the same process
is applied to the inbox_ui but the logic of muting/unmuting the topic
is kept in inbox_ui which uses function toggle_topic_visibility_policy
in user_topics_ui.
The function toggle_topic_visibility_policy is called in both
cases based on specific conditions to prevent the shortcut from
affecting other parts of the page, thus avoiding errors.
Fixes#27741.