The previous check looked at whether the settings overlay as a whole
was open, not whether the specific panel we're going to update was
rendered.
The other code paths calling from server_events_dispatch into this
module already correctly check meta.loaded.
When "group-pm-with" is the first operator and setting an empty
narrow banner, check that the operand matches a user and set the
title based on whether the user exists or not.
Updates the `filter.get_title` logic to return the list of users
for narrows that include the pm_with and near operators. That way
the browser/tab title remains the same for these views.
This change is made so that we are not accessing the global page_params
directly. Note that we also rename unread_msgs to params to match other
modules that follow this pattern.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
This setting provides a more ergonomic experience when viewing a
message where only a small number of emoji reactions are present; you
no longer need to hover over the reaction to see who reacted, which is
often quite important to understanding what it means.
We added this setting (visible in the development environment only,
and implemented on mobile) a few months ago; so to complete this
feature, we just need to add the frontend rendering/live update logic
and publish it.
As documented in the code comments, the current rule is "messages with
3 or fewer reactions" for which messages will display the names of the
users reacting.
The previous set_reaction_count API made sense when the display of a
given reaction was a pure function of its data. However, we will soon
be making it a function of the total number of reactions on the
message.
Thus, view functions to update reaction display now need to call a
shared update_vote_text_on_message function in all code paths, even
code paths like "add the first vote for a reaction" and "remove the
sole vote of a reaction" which previously did not need to call
set_reaction_count.
Fixes#20890.
Since stream header is now sticky, we need to reduce it's height
when calculation position of the element we want to scroll into view
so that it doesn't hide under the sticky header.
This commit introduces the change of rendering private messages
section as collapsible, whose data-fetching logic came with zulip#21357.
We now have separated out `Private messages` from `top_left_corner`
section and shifted it below the `global_filters` in a different
separate section along with stream list with common scroll bar
in left-sidebar.
The new PM section will be opened by-default on loading the page
and will have a toggle-icon in its header, clicking on which makes the
section collapse/expand accordingly.
In default view, only recent 5 PM threads would be shown
and would append the active conversation as the 6th one at last
if not present in those 5, similar to how topics list work.
In PM section with unreads, a maximum of 8 conversations
would be shown and rest of them would be hidden behind
the 'more conversations' li-item, clicking on which takes
to the zoomedIn view of PM section where all the present
PM threads would be visible and rest of the sections of left-sidebar
will get collapsed.
Fixes#20870.
Co-authored-by: Aman Agrawal <amanagr@zulip.com>
Removes call to reset_compose_message_max_height when clicking on
the markdown preview button, which due to the `#compose` div element
momentarily shrinking to be empty, caused the calculation of the
max-height to grow larger on each click.
Also refactors reset_compose_message_max_height to use the height
from `getBoundingClientRect`, which defaults to zero when empty.
And fixes a small discrepancy in how max-height is applied to
a div element vs a textarea element, so that the visible height
doesn't change between the preview and write modes in the compose
box.
Fixes#23277.
Updates the hash used for the recent conversations view to be
"#recent" instead of "#recent_topics".
We will need to keep the logic for handling "#recent_topics"
permanently because users potentially have messages from
Welcome Bot with links to that hash.
Including "recent_topics" as a web_public_allowed_hash in
hash_util.js can be changed once self-hosted servers cannot
upgrade directly to Zulip 5.x from the current version.
Fixes#23132.
The resize handler is a somewhat expensive operation, which we'd like
to avoid when processing the receipt of new messages. It's also
unclear why it would be necesssary; bottom_whitespace is fixed in
size, and the sidebars.
It should be very rare to discover new unread messages during a
message_fetch call. This can potentially happen due to races (fetching
just as a new message arrives), but it shouldn't be the common case.
Previously, we would trigger a full rerender of all UI displaying
unread messages every time a bulk message fetch operation returned
(including every time one narrowed), regardless of whether any actual
state had changed.
Fix this by actually checking if we discovered any new unread messages.
Because we can count on the unread.js data structures to be correct,
we no longer need this legacy code that tries to re-process all
messages the client has cached for whether any are present in the
target stream and marked as unread.
It's not clear we need this at all, since the current Zulip server
will mark all messages as read when unsubscribing from a stream, but
having this call protects us from future bugs should that behavior
change.
This cleanup also revealed a possible bug, where we would fail to
update global unread counts properly when unsubscribing from a stream
until the deferred_work queue processor sends us the
update_message_flags event associated with that change.
We change the "pm-with" and "sender" narrow urls
to be of "{user-id}-{encoded_name}" form instead
of using email. This change improves performance
of changing between PM views since parseOneAddress
function was slow and we remove its usage now by
using name instead of email.
The name is encoded such that the characters that
would be encoded by the browsers are replaced by
"-".
We should not show UI for moving locally echoed or failed messages.
For the edit/move icon in message controls -
- After 2451002, we showed "Move message" icon for locally echoed
messages when moving messages was allowed as per org permissions.
This was clearly a bug and this commit fixes it and we instead
show "View source" icon.
For "m" hotkey -
- After 2451002, pressing "m" opened "Move messages" modal for
locally echoed messages when moving messages was allowed as per
org permissions. This was clearly a bug and this commit fixes it
and pressing "m" does nothing.
For pencil icon in recipient header -
- Previously, the pencil icon was showed even if first message
below the recipient bar was locally echoed and the topic edit
failed silently with locally echoed or failed messages again
showing under old topic after reload. This commit fixes it
to hide the icon in such cases. The original behavior was
that server returned an error with not so appropriate
response.
- Note that we can only check the first message below the header
since it will be inefficient to check all the messages whether
each of them is successfully sent.
And in such cases when any of the later messages is locally
echoed, the topic edit succeeds but the locally echoed or failed
messages are shown under old topic after reload.
- The behavior is same for the "checkmark" icon for resolving
topics in the header.
For three-dot message menu -
- We don't need to do anything here since the three-dot icon
is not shown for locally echoed or failed messages.
For the "Move topic" option in topic popover in left sidebar -
- We cannot do anything here since it will be inefficient
to check all messages in the topic whether they are locally
echoed or not everytime we open the popover.
- If the first message in topic is locally echoed or a failed
message, then the id of first message of the topic returned
from server is undefined and we see an error in client while
trying to get message from that id. And if one or multiple of
the later messages is locally echoed, then only successful and
server-acked messages are moved.
Note that this cannot handle all cases like a user can use
a successfully sent message to access the topic edit UI
and then choose "change_all" and "change_later" propagate
modes. In such cases the locally echoed and failed messages
will remain in the old topic only.
We now do not test is_topic_editable function in
get_editability test for better readability and
this will be helpful when we will need to test
more cases as part of #21739.
This fixes a couple significant issues with the drafts logic:
* Previously, we would move drafts even when !going_forward_change; this
is inconsistent with the compose box logic on the previous line.
* The drafts.rename_topic() function did not handle drafts with
incomplete stream/topic fields correctly, throwing an exception in
that case; this resulted in user-visible live update problems
because code after the drafts.rename_topic call would not be
executed.
Fixes#22984
Add an `@` icon in unread topics where user is mentioned.
We track a new set of `stream_id:topic` pairs for the unread mentions
so that recent topics instantly knows if a topic is unread and mentioned
or not.
Previously, we allowed editing topic of "no topic" message, when other
conditions were not met, only from recipient bar but it is allowed
irrespective of other condtions. This commit fixes it to show the
"Move message" option and icon for "no topic" messages irrespective
of other conditions.
Previously, NO_LONGER type was just used to display
the text in the bottom-right of message edit form
which we have removed now, so we can remove `NO_LONGER`
type now.
Updates `filter.get_title` to return 'undefined' for any narrow
with a search operator. Previously it would return a title if
the search operator was paired with a common narrow, but those
results were not being used when building the message view
header and will not be used for setting the browser title.
Prep commit for rewriting `update_narrow_title` to use
`filter.get_title` as a helper for setting browser title text.
When the narrow/search for a stream is undefined because either the
stream does not exist or the user is not subscribed to the private
stream, format the title that's used in the message view header to
include the stream name that was searched for.
Prep commit for rewriting `update_narrow_title` to use
`filter.get_title` as a helper for setting browser title text.
Updates default title for `streams:public` narrow to be
"Messages in all public streams".
Prep commit for rewriting `update_narrow_title` to use
`filter.get_title` as a helper for setting browser title text.
In `filter.get_title`, add cases for the two missing "is" operators,
"alerted" and "unread".
Prep commit for rewriting `update_narrow_title` to use
`filter.get_title` as a helper for setting browser title text.
This commit adds private messages to the Recent topics view, to make
it an all-encompassing overview of recent activity visible to the user.
We add a filter "Include PM" to toggle whether PMs should be shown in
recent topics.
Fixes#19449.
Following the addition of support for custom profile fields in the
user info popovers, we redesign the popover to have a cleaner look.
* Switch top section design from centered to left-aligned.
* Move mute/unmute and manage user options behind a \vdots menu.
* Move the local time and status into a new block.
Almost all design changes ideas are from discussion on chat.zulip.org;
see "#design > pronouns in profile card" for details.
Co-authored-by: evykassirer <evy.kassirer@gmail.com>
Co-authored-by: Tim Abbott <tabbott@zulip.com>
Fixes#21757.
Previously the draft count would briefly increase between the action
of sending a message and the success of sending that message.
Now the draft count will only increase if the message fails to send.
We already offer this for stream messages, but had been blocked on
adding it for private messages for visual design reasons. The dark
theme had a natural place to put this, since it had a box around the
private message recipient box; but the light theme didn't.
We add a border to the light theme private message recipient box to
allow us to add the same button to private messages, and implement
that button.
Fixes#21962.
This also adds a comment noting a remaining performance bug we have in
this code path, namely fetching messages for a streams narrow will do
unnecessary work.
This script pulls from our previously custom-written emoji strings
and fills in the rest from CLDR. It also removes 4 custom emoji which
collide with some of the new CLDR names (they will now just be called
by their CLDR name).
We renamed the id from "subject" to "stream_message_recipient_topic" in
d7c2577ffb.
It is concerning that the tests are not actually failing while this id
has been wrong. The test case might have some redundant parts or is set
up incorrectly.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
This cleans up "subject" from test data and variable names. No extra
change is required for this kind of change as they are only locally used
in the test cases.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
This finishes up the work from 057ee6633a.
We had this "get_reload_topic" helper for user that has "topic"
encoded as "subject" from a older release. This is unlikely to cause
problem now because we no longer use "subject" for reloading since 2018.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
This removes the temporary get_draft_topic helper from utils and remove
references to draft.subject.
This finishes up the work from
9861cdfeb6. Since 2018 we had stopped
referring to the "subject" property, it is considered safe to remove
this code now. It's impossible to directly upgrade to the current
release without substantial downtime for upgrading the OS, so this
logic is unlikely to provide any future benefit.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
Since set_msg_edit_limit_dropdown and set_msg_delete_limit_dropdown
have almost same code except the ID of elements, we extract a common
function set_time_limit_setting and both the above functions call
this new function only.
We can use this function for topic edit limit setting which will be
added in further commits.
We now show save-discard widget on changing the message edit and delete
limit setting dropdown from any value to "Custom" only after value inside
the custom input is changed. This makes sense as the setting value is
not actually changed unless the custom input is not changed and also
makes the behavior consistent with realm-level default of notification
batching period setting.
After this change, the dropdown element and custom input element are not
considered as different setting elements for code purposes and are
treated as single setting like the realm-level default of notification
batching period setting. And thus we remove the prop-element class
from the custom input elements of these settings.
