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 adds a get_unread_message_count helper that returns the size of
unread_messages and replaces the usage of page_param.unread_msgs.count
elsewhere in the codebase.
Fixes#23334.
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.
We may want to rename clean_reactions to something else, but the name
`r` is pretty confusing for an object that isn't a single reaction,
but instead an object detailing all the reactions on a message.
Follow-up to commit 22a5d008c1.
The new display setting introduced in above commit was not registered
properly and enabling/disabling it from Organization settings > Default
user settings did not display a "Save/Discard" widget. This has been
fixed by modifying the `settings_org.get_subsection_property_elements`
function.
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>
Dropped text "(Message sent when you were not subscribed)" for
historical messages in the three-dot message menu.
This information was already available via the "You subscribed" type
divider lines, which were added about the same time back in 2013, and
this text feels somewhat ugly.
Also removed the historical field from the args object that is
passed to the template, as this is not used anymore.
Fixes#23198.
Updates the `filter.get_title` logic to return the stream name for
narrows that include the stream, topic and near operators. That
way the browser/tab title remains the same for these views, which
have a particular scroll offset.
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.
This gives us some time to render and fetch data before allowing
user to start using hotkeys. It avoids error being thrown when
hotkeys are used when the app is still loading.
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.
There's no reason that opening left sidebar popovers should require
the app to recalculate the size of any of its components; popovers are
drawn on top of the rest of the UI in any case.
This appears to have been added in
9ed05a1f85 as part of prototyping the
left side user list feature.
This was likely introduced in error in
fd66d9f70336b2bdbbffb1bf13402516b9920682; it is a duplicate of
show_userlist_sidebar, which, in contrast is actually called.
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.
The previous invocation message_util.do_unread_count_updates dates
from a time when `unread.js` did have any data beyond what full
message objects were present in the client, and thus we needed to
recalculate everything from those message objects when muting state
was changed.
With the modern unread.js data structures, all that's required is a
full recalculation/rerender via this function.
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
"-".
This commit fixes the issue where the 3-dots menu icons on the left
sidebar disappear even though the associated popover is open by
toggling a special CSS class on the menu item. It follows the same
approach used by the emoji picker on the message feed UI.
Fixes #23157
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.
The message_hover function in ui_init.js had an if condition
to return early when is_topic_editable was false. We instead
change it to return early when message.sent_by_me is false
since in that case the edit_content element is not present.
Note that we also show the "View source" icon when message
is locally echoed or not sent successfully.
Till now is_topic_editable is always true when message is sent
by the user itself, and when message is sent by someone else
the edit_content element does not exist in the DOM anyway. So,
basically, it just helps in returing early and not unnecessarily
move forward to set html for a non-existent div. So, we can
ideally replace it with just `sent_by_me` condition and otherwise
we already show the reaction icon.
The comment above that also mentioned that "locally echoed messages
have !is_topic_editable" which is not true since is_topic_editable
does not check whether the message is locally-echoed or not. This
comment was added in e1c4c7b80.
This also fixes the bug where "View source" icon is not shown when
"message.sent_by_me" is true and both editing and moving message
is not allowed which currently happens when allow_message_editing
setting is False.
Also, the "is_topic_editable" condition will be not valid in future
when "is_topic_editable" can be false when "sent_by_me" is true. In
such cases we would not show any icon then, so better to fix this
here.
Some history of this code-
- Intially we returned only when !sent_by_me was false, but added
a condition to return early when realm_allow_community_topic_editing
was false in 91197fa4f1. Though it was not needed since edit_content
element amyways did not existed when `sent_by_me` was false.
- Then the condition was then changed to return early if
is_topic_editable was false in 689c717284.
We do not allow sending messages where sending request had failed
or message is locally echoed. This commit extracts these checks
to a new function so that we can avoid duplicating code.
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.
Replaces instances of "recent topics" in the web-app and documentation
to be "recent conversations".
Renames both `recent-topics.md` files in the help center to be
`recent-conversations.md` and updates/redirects links to new URL.
Does not update instances of "recent topics" in frontend code comments
and does not update the main overview changelog, for now.
Does not change case study text where "recent topics" was referenced
in a quote, but does change generic text references to be "recent
conversations".
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.
This change is to match the behaviour of page up/down on messages.
So, If you hit PageUp/Down while there's no additional pace to scroll,
we move the selected topic to the first/last topic as appropriate.
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.
Renames the help article on custom profile fields to reflect that
its content is not just about adding fields.
Adds a redirect from the old URL to the new URL and updates internal
links, linking to #add-a-custom-profile-field where appropriate.
Fixes#23170.
Fixes#23078.
Instead of relying on browser, we handle the page up/down keys
to ensure we take care of some rows being hidden due to compose
box and table header.
Previously, the on_topic_change handler for the compose system would
focus the compose box after a topic change, and also select all content in
the compose box. Selecting that content makes sense if we think the user's
intent is likely to be deleting that content; but there's no clear reason we
should expect that intent, and it's not particularly consistent with our drafts
model to risk accidentally losing partially composed message content this way.
After some discussion, we've concluded that in both cases reaching this code path
(either the previous topic being "" or the compose box content being entry), it'd
be better to skip the `.select()`.
Fixes#23146.
Sets a default value of "Search results" for complicated narrow search
views and updates logic to use `filter.get_title` as a helper to
generate better titles for some common search views.
Does not update the existing behavior for narrow searches that have
"pm-with" or "group-pm-with" operators.
Note as of this change, the default search title and titles generated
from `filter.get_title` will be translated into the user's preferred
language.
Fixes#22952.
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.
Fixes a subtle bug in the browswer title that occured if the user
input a keyword or another vaild search operator before `pm-with`
or `group-pm-with`.
Prep commit for rewriting `update_narrow_title` to use
`filter.get_title` as a helper for setting browser title text.
Translates browser titles for "All messages" and "Recent topics"
views.
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 avoids an error being triggered if `instance.reference` gets
remvoed from the DOM and `rows.get_message_id` is called on it in
`onShow` later.
This is an untested bug fix since I was not able to reproduce
this on live server or locally.
Previously, we retried all failed requests to
`/json/messages/matches_narrow` forever, with a fixed 5s retry. This
meant infinite retries even on 4xx responses, for instance on invalid
narrows -- and _each_ new message would add another infinite every-5s
retry.
Skip retries on 400 responses, and put an upper limit on the number of
retries. At the same time, change the retries to be
exponential-backoff with full jitter, to be more responsive in the
event of a one-off failure, and more forgiving in response to a longer
outage.
Failures that exhaust the 5 attempts are silent to the user -- since
this is likely an uncommon edge case (requiring Tornado to be serving
events to the client, Django to be unresponsive, and the client to be
narrowed to a filter it cannot apply locally), and the failure mode is
not bad (it will simply fail to live-update with new matching
messages).
Fixes: #20165.
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.
Adds the count of users with the role of guest to the stats view
`page_params` via a database query. This information is then added
to the summary statistics section of the analytics page after being
formatted by `stats.js`.
Creates Bassanio as a guest user in the database for the analytics
realm.
Fixes#20162.
Send an empty list of `custom_profile_fields` in `page_params` for
spectators, rather than not sending the field at all.
Also, updates the user info popover to not show the manage user
three-dot menu when in a spectator view.
When trying to open settings overlay with invalid hash or
hash of a section which the user cannot view, for example
non-admins cannot view custom profile field section, then
we open the first section by default.
While if a user changes to a invalid hash by typing when
the overlay is already opened, then the previous section
remains open.
Fixes#23163.
We now disable the topic or stream input in move message modal if
user is not allowed to edit them. Topic input can be disabled only
in the modal opened from message actions popover since permission
to edit topic depends on message and we do not have any message
when we open topic from left sidebar since the message is fetched
from server while submitting.
This commit also does some changes to call ".trim()" on new_topic_name
only when it is undefined. new_topic_name can be undefined when
the new topic input is disabled because "serializeArray" only
considers enabled inputs.
Previously, we showed "View source" icon if content editing was not
allowed, now we show the move message icon instead if moving message
is allowed but content editing is not. We remove the hotkey from
tooltip for now and would add a different hotkey for moving
messages in further commits.
We also add a common class for all the three icons in this commit
to avoid duplication and use different class if required for click
handlers.
Previously, we allow moving message (both topic and streams) in
the message edit UI and we opened message edit UI when clicked
on "Move message" option in message three-dot menu. Now, we open
the "Move topic" modal (that is opened when using "Move topic"
from topic sidebar) on clicking "Move message" option in
message three-dot menu.
We remove the hotkey "e" from "Move message" option for now since
both edit and move UIs are different now. We will instead add
new hotkey in further commits.
We pass stream_id as undefined when stream is not changed. This is
required for case when only topic editing is allowed. It worked
previously because we show "Move topic" option in left sidebar
only when stream editing is allowed.
We now allow only content edit in message_edit_form which can
be opened by pencil icon in the message row, "Edit message"
option in popover and by using e hotkey.
As a result of this change, we also do not show topic and stream
edit options when using "View source" options.
We would instead support changing stream and topic from the modal
which will be opened from the "Move message" option in message
actions popover.
We should uncheck the display_in_profile_summary checkbox in the
custom field creation form if the checkbox is hidden, like for
LONG_TEXT or USER type fields which are not allowed to be
displayed in profile summary.
This solves the bug where a user initially checks the
display_in_profile_summary field and then changes the type
to LONG_TEXT or USER where the checkbox is hidden but it
still remains checked and thus the request to server is made
with display_in_profile_summary=true for which server returns
error.
Fixes#23171.
Previously we did not send notification for topic-only edits.
Now, we add backend support for sending notification to topic-only
edits as well.
We would add support for this in webapp in further commits since
message edit UI will be updated as well. We just make sure that no
notifications are sent when editing topic using pencil icon in
message header.
We also change the API default for moving a topic to only notify the
new location, not the old one; this matches the current defaults in
the web UI.
Includes many tests.
We also update the puppeteer tests to test only content edit as
we are going to change the UI to not allow topic editing from
message edit UI. Also fixing the existing tests to pass while
doing topic edits is somewhat complex as notification message
is also sent to new topic by default.
Fixes#21712.
Co-authored-by: Aman Agrawal <amanagr@zulip.com>
Co-authored-by: Tim Abbott <tabbott@zulip.com>
Array#findLastIndex is new in ES2023, but is polyfilled with core-js ≥
3.16 and supported in Node.js 18.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
We want to be able to differentiate between the stream and the topic
in the title bar, but the current implementation displays both the
steam name and the topic name in the same way which becomes difficult
to comprehend at a glance.
In this commit, we make the following changes,
- <stream_name> to #<stream_name> (when viewing the entire stream)
- <topic_name> to #<stream_name> > <topic_name> (when viewing a topic)
These changes help us differentiate between a stream and a topic with
with a quick glance.
Fixes#22969.
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>
Because some button text is much longer in different languages,
there is an existing bug when the charts are rendered with the
range selector buttons positioned on the right side of the chart.
This positions the range selector buttons to the left side of the
chart and the hover information to the right side of the chart.
For the pie charts and horizontal bar chart, the grouping buttons
labeled "Me" and "Everyone" are moved to the top of the chart, which
matches the grouping buttons on the vertical bar charts.
Adjusts some chart margins for new positioning of buttons and hover
information. Deduplicates some shared code for rangeselector buttons
in `stats.js` for the three vertical bar charts.
Updates the font-family and font-size for plotly charts so that
the text in some legends is no longer cut off.
Updates the tick angles of the vertical bar charts so that the
x-axis text never becomes angled when moving the rangeslider.
Fixes#18912.
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.
Adds the realm's used storage space for attachments to the stats
view `page_params`. This information is then added to the summary
statistics section of the analytics page after being formatted by
`stats.js`.
Uses the emoji test image to create an `Attachment` in the database
for the analytics realm. Even though it doesn't create a message
to claim the attachment, it still is sent as storage space used
data for the analytics `/stats/` page.
While creating a pronouns type field, "display_in_profile_summary"
checkbox is checked by default for "Pronouns" type field if the
limit is not reached.
Fixes#21271.
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.
Zixuan James Li
Tim Abbott
Raghav Luthra
Aman Agrawal
jai2201
Barissa-Imran
Rebecca Södereng
Lauryn Menard
Sahil Batra
Rishant Rokaha
Eyuel Berga Woldemichael
Ganesh Pawar
evykassirer
Akarsh Jain
Yogesh Sirsat
David Rosa
Joseph Ho
Alex Vandiver
madrix01
Julia Bichler
Anders Kaseorg
sayamsamal