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
"-".
Now that we show the \vdots icon while the actions popover is open,
there's a weird looking behavior where a focus outline appears around
the \vdots icon, only if you clicked on the icon itself, not its
square containing click arrow.
Disable this unintended behavior, which disrupts the otherwise
simulated state where focus is in the popover (but no row is focused).
The color for the message control buttons is set in the
`message_control_button` class. The `reaction_button_visible` class
also sets a color declaration with the same value.
This commit removes this declaration because it doesn't change the
color of the reaction icon(the class is currently only used in
conjunction with `message_control_button` to toggle the button
visibility) nor does it override any inherited style (hover color
remains the same regardless) as it lacks an `!important` rule.
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
This commit enables the 3-dot menu to be visible while the associated
actions popover is open using the fact that the 'has_actions_popover'
class is attached to the message with an open popover. This approach
solves the bug without any additional JavaScript code.
Fixes part of #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".
Previously, we had some special CSS for the user profile modals in the
case that there were no custom profile fields, to do things like hide
the <hr> divider between the normal profile fields and custom ones.
The design has for some time treated custom profile fields as just
additional profile fields; so there's no longer a need for custom CSS.
While going through the full profile of a user, we expect to find
that specific user's in-depth details. Thus, we should have a fixed
title displaying the name at the top of the modal to establish the
connection of the profile data with the user.
We also fix the tab switcher between "Profile/Streams/User groups" to
the top of the modal, for the added convinience of switching across
the three options at any point of time.
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.
We seem to override this setting for most of the dropdowns, so this
common CSS only applies to the smaller dropdown shown to logged-in
users, where it was weirdly wide.
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.
Tim Abbott
Sahil Batra
Rishant Rokaha
Eyuel Berga Woldemichael
Aman Agrawal
Ganesh Pawar
evykassirer
Akarsh Jain
Lauryn Menard
Julia Bichler
sayamsamal
Yogesh Sirsat
Noble Mittal
David Rosa