Fixes part of #30918.
We don't need `align-self: baseline;` for `fa-envelope` set in
`message_view_header` since this is a different icon and it appears
better without it like other icons.
We also don't need the explicit font-size for switching b/w 14px and
16px mode since `zulip-icon` class takes care of that by default.
This commit updates the banner text in the case of message sent
while in search view to match the narrow_to_recipient_banner text
displayed in other cases.
Earlier, on sending a message while narrowed to a search view
'!can_apply_locally()' resulted in error during local echo.
Reason:
In 'insert_new_messages' the call to 'maybe_add_narrowed_messages'
needs message ID to make a GET request to '/messages/matches_narrow',
but during local echo message ID is not available. We were using
'local_id' (a float) resulting in 400 error response.
Fix:
This commit fixes the bug by skipping the discussed GET request
during local echo.
Earlier, on sending a new message in a search view it didn't
appear in that view for the sender.
This was because the message event received by the sender
was processed by 'msg_list.view.rerender_messages' which
effectively did nothing because the message is not
rendered in the first place during local echo in that
message list view.
We can't determine locally if the message should be added
to the search narrow. So, we use maybe_add_narrowed_messages
when narrowed to such views.
This fixes the bug and the message appears in the search view.
Previously, when a link containing the "with" operator in an incorrect
narrow is loaded, it used to open the correct view with the wrong
title of the message view header.
This commit fixes it by re building the message view header title
in case the narrow for the "with" operator has changed.
Previously, while using "with" operator, even when the narrow
was not updated by the operator, hash change requests were
made.
This commit introduces a new variable - "narrow_requires_hash_change"
which determines whether the narrow was updated and thus
requires a hash change or not.
Fixes#30862
Some time ago, I added a condition to not reset
the search bar if the user had already started
typing, so that we wouldn't erase what they'd
started typing. But we encountered a situation
where the search bar can be opened with text in
it: clicking "searching all public channels"
from a search view. We want to reset the searchbox
to add the `channels: public` pill.
I tried to replicate original issue I encountered
where the search box resetting was clearing user
input and couldn't replicate it. So for now I'm
just removing that if statement.
This commit updates "filter.is_conversation_view" to be true for
"with" operator. This is important because essentially, the "with"
operator lands you in the same view as the channel-topic narrow
or the "dm" narrow i.e., the last unread message of the narrow.
Hence, the "with" narrow should be handled in a similar way
while determining whether to allow automatically marking
messages as read, or displaying the unread banner, etc.
Fixes#30863
The "Dense mode" checkbox is renamed to "Compact mode" and is used
to toggle between changing the font-size and line-height settings
between 14/122 and 16/140 configurations.
In an interleaved view when composing a message we fade messages
which the user is not replying to, to reduce the chance they send
a message to a recipient they didn't intend to.
Also, it reduces the visual/cognitive processing required
to figure out where their message is going to go.
But, it's not necessarily clear to users that what the
fading means, so this commit adds a one-time compose banner
to explain what's going on the first time this comes up.
Fixes part of #29076.
In a non interleaved view when composing a message to another
conversation we fade messages which the user is not replying to,
to reduce the chance they send a message to a recipient they didn't
intend to. Also, it reduces the visual/cognitive processing required
to figure out where their message is going to go.
But, it's not necessarily clear to users that what the
fading means, so this commit adds a one-time compose banner
to explain what's going on the first time this comes up.
Fixes part of #29076.
Earlier in search suggestion, has: operator returned two different
suggestion string which were `messages with one or more links` and
`messages that contain links`.
This commit changes this to a consistent suggestion string.
Fixes: zulip#30908
This commit extends the work in #29302 to support the new
"channel" operator, which is synonymous to the "stream" operator
in transforming stream-topic links to the #**stream>topic** syntax.
This commit removes the unnecessary conditionality that used
to check if the channel and topic of the filter operands in the
"_possible_unread_message_ids" method while checking for
"can_bucket_by("channel", "topic", "with")".
This conditionality is unnecessary essentially because the code path
is executed only when "requires_adjustment_for_moved_with_target"
is false, which happens only after the narrow containing the "with"
operator is adjusted to the correct narrow. Else, it remains true.
Previously, when "adjusted_terms_if_moved" was called for non stream
messages, it used to return "null" for adjusted terms. This is true
for some extent since the non stream messages can not be moved.
However, in case of narrow containing "with" operator, this would
be buggy since there, we want the narrow terms to be adjusted
according to the "with" operand to point to the current narrow,
rather than returning null.
This commit updates the method to return null only if the "raw_terms"
dont contain "with" operator. Else, adjust the "raw_terms" according
to the message.
The commit creates a `server_message.ts` module which
will home our `zod` schema for the messages received
from server. We can then import the schema to parse
the data in needed modules at the API boundaries.
This will also help us write better tests.
We used to just drop moved messages from the list of messages to
update if we didn't have them cached. So, if the user is in the
narrow where messages were moved to, user will not see the moved
message if they were not cached locally.
To fix this, we re-render the narrow after fetching messages from
the server.
We don't want to use `fast_track_current_msg_list_to_anchor` here
since that function assumes that current rendered state of the
message list is correct which is not the case here.
ClipboardJS attaches event listener to the object when an
instance is created. We don't need to add an additional onClick
event listener to invoke it's functionality.
Fixes#30776.
`.advanced-settings-status` was being used at a few places for User list
status, that's why it's been replaced with
`.information-settings-status`.
This was introduced in 87635b9e32 and kept
getting renamed over time and did not get deleted. Other statuses'
`.hide()` got deleted over time. I'm not sure why we were using the hide
in the first place, but manual testing shows no behaviour change when
removing it.
We've renamed `get_all_preferences` to
`information_section_checkbox_group`. We've also converted it from a
function into a dictionary since it doesn't contain any page_params
variables anymore. This is a preparatory commit for adding a new
`Information section` as part of a layout change for this page.
`high_contrast_mode` was part of the checkbox group obtained by calling
`get_all_preferences`. For the new layout change, it will not be a part
of that group and this is a preparatory commit seperating it out from
that group. We will also rename that checkbox group in future commits.
These values were only a part of `DisplaySettings` type objects. We're
moving them out of these type of objects to be a standalone object of
its own. This will make it easier to reference in the next few commits
when those `DisplaySettings` objects would be broken down into different
sections.
We've excluded the new function from coverage since there's not much to
be tested there and similar settings functions do the same.
I'm not actually sure if this is possible; it's been copy/pasted from
the channel/topic code path, but even with that one, it seems like the
topic being `undefined` is impossible (that's not how operators work),
and the channel being undefined might be something that should fail in
`Filter` initialization, not here.
Adds server and web app support for processing the new `with`
search operator.
Fixes part of #21505.
Co-authored-by: roanster007 <rohan.gudimetla07@gmail.com>
Co-authored-by: Tim Abbott <tabbott@zulip.com>
