Without this, if there was a success compose banner and user pressed
escape key, no banners were hidden and the same behaviour was repeated
without compose ever closing.
Previously, when a user marks messages as unread in the all messages view
then enters another view and finally back to the all messages view, they'd
notice that the reading state in all messages view is still paused.
This happened uniquely for "All messages" because we only resumed the "reading"
state in `narrow.activate` (and generally that would generate a new MessageList anyway);
but `message_lists.home` is a singleton, so the "no longer reading" state would remain
attached to that object forever.
Fix this by explicitly resuming the reading state when we enter all messages
view/message_lists via narrow.deactivate.
Set data-tippy-trigger="mouseenter" on mute icon in recent
conversation to prevent tippy from staying on when the mute icon
is focused after clicking it. (The Tippy default is "mouseenter focus").
Rename get_muted_topics to `get_user_topics_for_visibility_policy()`,
since it works for both muting and unmuting.
Additionally, inline rerender_for_muted_topic, as well as removing
most of the logic to diff the sets of muted topics; the event is for a
single topic being changed.
Co-authored-by: Hardik Dharmani <Ddharmani99@gmail.com>
This commit refactors the logic of the 'all messages' view to
display messages from unmuted topics within muted streams.
Previously, we hid all messages from muted streams except mentions
by checking if the stream was muted. With this new change, we also
check for unmuted topics within muted streams using the
'is_topic_unmuted' function inside 'user_topics', which returns
'true' if the topic is unmuted. If there is any unmuted topic, we
show the messages from that topic in the 'all messages' narrow.
Live update was handled by the previous commit.
Fixes part of: #24243
We can dramtically simplify the stream muting live-update code path
for updating home_msg_list by observing the only thing it was doing
intentionally differently from update_muting_and_rerender is replacing
_all_items with a new version computed from from all_messages_data,
and the rest of update_muting_and_rerender can handle the live update
correctly unmodified.
This deduplication means live-update of "Unmute topic" just requires
updating the `in:home` filter logic appropriately, without any special
live update work.
Previously, the email had a line that says "Click the button below". This
sounds weird as the plain text emails don't have buttons and only had links.
We should change "Click the button below" to "Click the link below" which
makes more sense.
Created a new function choose_topics that loops through the topics
and push filtered topics using should_show_topic function to items
array if not zoomed else just push all topics directly to array.
If stream is muted and not zoomed call the choose_topics function
twice, first with passing unmuted_topics and second time with passing
remaining topics. else, call it only once with topic_names.
Fixes part of #24243
When user marks messages as unread, we used to rerender them but
that was not required since we only need to add `unread` class
to their `message_row` to achieve the same effect.
When selecting a previously selected message after a re-render,
we don't need to mark it as read. This caused a bug where
user cannot mark the selected message in a narrow as unread.
Also, added an additional check to only select messages if the
message is re-rendered in the currently visible message list since
you cannot select a message in a view which is not visible.
Updates areas in the API documentation that reference the maximum
length of a stream message topic to note the `max_topic_length`.
Updates areas in the API documentation that reference the maximum
length of a stream name to note the `max_stream_name_length` and
areas that reference the maximum length of a stream description to
note the `max_stream_description_length`.
All of these maximum values are sent by the `POST /register`
response.
We now open the stream dropdown if a user presses "Shift+Tab" from
topic input in the compose box, instead of just changing the focus
to be on dropdown toggle button.
This helps reduce the amount of import cycles we have in the compose
code path following the migration to a fancier stream input.
`compose_closed_ui.initialize()` was moved further down in the
initialization order because it relies on the dropdown widget
to be defined.
This is needed for the compose stream dropdown widget,
which is also updated here. Now when a user is subscribed
or unsubscribed from a stream, or a stream is renamed, or
or a stream is deleted, the dropdown widget updates
accordingly. This fixes a regression of this functionality
that happened during the switch to the dropdown.
These were previously used in the input form field and
this commit removes the code that supported that and
replaces it by using existing dropdown_widget functionality
to display the icons in the compose dropdown.
Fixes#11832
This lets the user see more options than the three that appear
in the typeahead menu, and prevents them from inputting invalid
stream names.
This change replaces the input field with the dropdown, and
updates everything that referred to the classnames of the old
input field, so that they now get the data they need from the
new dropdown.
Previously, we stopped the composebox from closing on
in-composebox clicks by stopping propagation from the
composebox click handler. This was an issue because
we need to propagate the event to bootstrap in
situations like dropdown clicks. We can avoid closing
the composebox on in-composebox clicks by just checking
if the click is in the composebox.
This is a helpful prep commit for the upcoming compose
stream dropdown, which needs to change the list of
stream names when the user changes their stream subscriptions.
After merging #24423, it was found that there were still an email yet to be updated with the new lines introduced in that PR. This commit updates both the email and plain-text versions.
This is a continuation of #24260 where we have redrafted the "contact us"
line in various emails, but the plain-text versions of those emails remains
untouched. We want to also update those versions and ensure that they match
with our emails.
Fixes: #25198.
This commit sets the transition to "none" for the dropdown
list widget element during focus to remove a weird fade-in
effect. We have to set this to none as the existing CSS
sets transition for all button elements inside ".new-style"
div. This commit adds the CSS for select element too,
as both are using same CSS, but since there was no transition
effect for select elements before as well, we can do this
change safely.
Updates the empty narrow banner when there are no starred messages
for a more general use case. Previously, it indicated that the
user hadn't starred anything yet, which could be confusing for an
experienced user who had just cleared out their starred messages.
Several onboarding emails sent to new users/organizations used the
same "contact us" language. Adds new macros for the "contact us"
line for Zulip Cloud and self-hosted realms to eliminate repetition.
The suitable macro for Zulip Cloud vs self-hosted organizations is
decided conditionally, by checking corporate_enabled.
Fixes#24260.
This prep commit renames 'muted_topic_ui_row.hbs'
to 'user_topic_ui_row.hbs'.
This includes minor refactoring, as it is now the
template for rows with any visibility_policy,
not just MUTED.
This is a prep commit that renames 'get_muted_topics'
to 'get_user_topics_for_visibility_policy'.
The function is refactored to add support for
visibility policies other than MUTED.
Installs which are upgrading to current `main`, and are upgrading for
the very first time from an install which was originally from git,
have a `/home/zulip/deployments/current` which, unlike all later
upgrades, is not a `git worktree` of `/srv/zulip.git`, but rather a
direct `git clone` of some arbitrary URL. As such, it does not have
an `upstream` remote, nor a cached `zulip-git-version` file.
This makes later attempts to determine the pre-upgrade revision of
git (for pre-deploy hooks) fail, as without a `zulip-git-version`
file, `ZULIP_VERSION` is insufficiently-specific (e.g. `6.1+git`), and
there is no guarantee the necessary tags exist either.
While we can make fresh git installs set up an `upstream` and run
`./tools/cache-zulip-git-version` going forward (see subsequent
commit), that does not address the issue for deploys which already
exist. For those, we must configure and fetch a `remote` in the old
checkout, followed by re-generating a cached `zulip-git-version`.
Fixes: #25076.
Aman Agrawal
Lauryn Menard
Joseph Ho
Hardik Dharmani
Daniil Fadeev
Alex Vandiver
Tim Abbott
palashb01
Joelute
Sahil Batra
evykassirer
N-Shar-ma
alik-balika
David Rosa
Alya Abbott
Anders Kaseorg
Ujjwal Aggarwal
Prakhar Pratyush