Inspired by #19821. The original proposal in #19821 got bogged down with
issues around multiple overlapping tooltips, but this seems like a useful step
forward.
By implementing a careful flexbox declaration on a new banner-
element container, this presents banners accessibly across the full
range of possible viewports--and relies only on a single, small
media query to do so.
Fixes: #25847
Co-Authored-By: Hardik Dharmani <Ddharmani99@gmail.com>
Added a show_unread_counts personal user setting to the
Settings > Display settings > Advanced section which
lets user choose whether he/she wants to see unread messages
count on the left sidebar for streams.
This setting have three options,
"All Streams" - This will show unread messages count for all
streams.
"Unmuted Stream" - This will be default option and it will
only show unread messages count for unmuted streams.
"No Stream" - This option will not show unread messages count
on any stream.
Fixes#24149
This is a prep commit for introducing new "Show unread counts for" user
display setting. We should use css classes like `.hide` to hide the unread
count from the DOM as opposed to using `$unread_count_span.hide()` because
this injects inline styles and hence we won't be able to change the `display`
style on hovering for unread counts.
This is a prep commit for the new setting `stream_unreads_display`.
Before when a stream was active i.e. once you are viewing topics in
the stream we had a `active-filter` class applied to the stream `li`
but if we were viewing a topic then the `active-filter` was removed
even though the stream was still expanded.
Added a new class `stream-expanded` which persists even when we are
in a topic view, this is useful for knowing whether a stream is
expanded or not within css.
This commit introduces a new behavior for the search bar. Now, if
the search keyword is 'sender:', it displays the title of the user/me.
for example: sender:me
title: Messages sent by you
sender: Palash
title: Messages sent by Palash
for the implementation, we already have the check for 'dm:', which is
similar to this so just added a new if check for 'sender:' and return
the title accordingly.
Fixes: #18690
Currently, `is_common_narrow` relies on `calc_can_mark_messages_read`
to check a number of filters that are "common narrows" (which means
they have a special message header title and different behavior when
exiting a search view).
Creates a helper function,
`single_term_type_returns_all_messages_of_conversation`, that is
used in both the above functions.
The check for an empty array of term types is unnecessary for
`is_common_narrow` because the "All messages" view has an undefined
filter and the "in-home" term type used in the "zhome" message list
is covered. So that empty array check is not moved to the helper
function, and instead stays only in `calc_can_mark_messages_read`.
The helper function checks for a single term type (except in the case
of topic, which is checked in combination with stream) that will return
all the messages of a conversation.
To ensure consistency in the function, split the combined if
condition of in-home and in-all, further improved the comments, and
deleted the unnecessary ones.
Buttons which change the content in the compose textarea were so far
enabled even in preview mode, and would work, but those changes would
not be reflected in the visible preview. This is extremely confusing,
and can lead to the possibility of a user accidentally changing the
content of the compose textarea while previewing, and sending that.
Now we disable those buttons in preview mode, both when composing a new
message and when editing an existing one. We still show the tooltips,
but grey them out and make them unclickable.
Fixes: #20962
This commit removes the code to initialize
"realm-default-notification-sound-audio" element from
"notifications.initialize", because we do not need this
now as the previous commit added code to initialize it
in "settings_realm_user_settings_default.set_up".
This change works because the realm default notification sound
can only be played from the settings UI and so it is fine to
initialize it only when opening the default user settings panel.
Fixes#25744
By rendering the emojis after initializing the simplebar container,
the rendering time is decreased by ~30% as observed at 6x CPU
cooldown on mac i7.
This naming more accurately reflects the functionality of these types
of functions. They are not only responsible for displaying the
popovers but also for toggling them off.
The intent behind this commit is to tidy up how we handle user info
popovers. The first step is to move everything related to them into
its own module. This commit should not have any functional changes.
This commit aims to extract all logic related to obtaining
notification title from the `process_notification` function into
a separate `get_notification_title` function.
This commit aims to extract all logic related to obtaining
notification key from the `process_notification` function into a
separate `get_notification_key` function.
This commit aims to extract all logic related to debugging the value
of `notification_source` from the `process_notification` function into
a separate `debug_notification_source_value` function.
This commit aims to extract all logic related to obtaining
notification content from the `process_notification` function into a
separate `get_notification_content` function.
Also register these click handlers just on the popover itself directly
in the onMount helper, like we do with all the other popover_menus.js
functions.
stream_popover.is_open() much more accurately describes what this
does, and in particular the fact that the function applies to all
places the stream popover might be.
Commit 61f7ede43c (#25759) introduced a
bug: browser_history tried to access user_settings.default_view at top
level as soon as it was imported, before
user_settings.initialize_user_settings has been called, so
browser_history.state.spectator_old_hash was always initialized to
"#undefined".
Signed-off-by: Anders Kaseorg <anders@zulip.com>
For sorting topics in the left sidebar topics list, the "Followed"
topics are treated the same as "Unmuted" topics.
In a muted stream and not zoomed state:
* followed/unmuted topics at the top.
In an unmuted stream or zoomed state in a muted stream:
* normal recency sorting
The reason is that the "Followed" topics have a tier of interest
above being unmuted, so they shouldn't lie below the "Unmuted" topics
in the list.
This commit adds the follow icon to the right end
(before the three-dot menu icon) of the topic list item
for followed topics.
The icon replaces '@' instead of showing both the '@' and "Follow"
icons in the case of unread mentions, as users don't care if they
are following a topic if they've got unread mentions there.
In a muted stream, the text color of followed topics in the topic list
is set to be similar to that of unmuted topics.
The reason is that the followed topic has a tier of interest above
being unmuted, so it shouldn't stay faded in the topic list.
This commit adds the CSS variable '--color-unmuted-topic-list-item'
for the unmuted topic's color in the topic list.
The color for both the light and dark themes is defined in
'zulip.css' and used in 'left_sidebar.css'.
This approach helps to remove the use of the selector 'unmuted_topic'
only for color definition in 'dark_theme.css'.
We don't have a "Manage user" tab in your own profile, so it would
throw an exception to do the default thing here, and the mechanism for
editing your own settings should be the main "your profile" panel,
which is a bit bigger and more user-friendly.
I'm not totally convinced that the extra logic for not having a
"Manage user" tab is worth it; the alternative of figuring out a
non-confusing label would not be terrible here. But this version is
non-broken, and it'll be easy to change later if we change our mind.
This commit adds Tippy tooltips to the edit pencil button
in the user profile. Now, when a user opens another user's
profile, they will see the tooltip 'Manage user', and when
they open their own user profile, they will see the tooltip
'Edit profile'.
This commit unsets the padding of the bot icon and, as the anchor
tag has been replaced with the i tag, we have also set the color
and pointer. This is done so that when the user hovers over the
icon, it will appear as a clickable button.
This commit moves the bot icon to the left of the name in the user
profile and adds a margin-left and margin-right to the name to ensure
there is enough space between the icon, name, and edit pencil.
This commit redirects the edit pencil in the user profile modal to
the 'manage user' tab whenever a user with permission to manage
other users via the user profile opens another user's profile.
However, we still want to redirect the edit pencil to
'settings/profile' if the user opens their own profile. The user
management permission is granted if the user is an admin or the
owner of the bot. However, we do not want system bots to have
access to the edit pencil or the 'manage user' tab. Therefore,
a new variable called 'can_manage_profile' has been introduced
to manage all these permissions, and the CSS has been updated
accordingly.
To redirect to the manage user tab without opening another modal,
I have extracted the toggler. This toggler will store the
component, and if the edit pencil button is clicked, we can use
the goto function to redirect to a different tab.
Changed the id names of both the edit pencil icons to explain
better of what they do.
This commit increases the gap between the labels and input/select
of the user profile manage user/bot tab for clearer visibility.
It also reduces the gap between the 'deactivate user' button and
the last input to make it look better.
This commit disables the "Deactivate User" button inside the
"manage user" tab in the user profile modal. Additionally, a
tooltip is applied to the button by wrapping it inside a div
with the tooltip applied.
This commit fixes the inconsistent height of the user profile when
switching tabs. We now have four tabs in the user profile:
"Profile," "Streams," "User Groups," and "Manage User." However,
the "Manage User" tab has footer buttons that need to remain
sticky at the bottom without changing the overall height of
the modal.
To achieve this, we wrapped the footer inside a div element and
assigned it a class called "manage-profile-tab-footer." The main
body of the user profile is given a height of 60vh. However, for
the "Manage User" tab, we decreased this height to 52vh and
allocated the remaining 8vh height to the div element to
accommodate the footer buttons. This ensures that the user
profile maintains consistent height when switching between tabs.
However, we have a 1px border in the footer, so to ensure that
the height is consistent, we reduce the height of the modal
content by 1px, making it calc(52vh - 1px).
To implement this, CSS code was added to the "popover.css" file
and accessed through the class specified in the "user_profile.js"
file.
The default padding of the buttons inside footer is 20px, but
with the above solution on large screens the buttons are not
aligned properly, so removed the padding top and bottom
and instead applied the flex box and property to align the buttons.
This commit migrates the "Manage Bot" modal to the user profile modal,
with the same explanation as in the "Manage User" modal commit.
However, in this commit, we changed the permission of the "Manage User"
tab so that non-admin users can also see the "Manage Bot" tab if they
have created the bot. Additionally, since we can't make changes to
system bots, we check if the bot is a system bot and hide the
"Manage Bot" tab accordingly.
Fixes: #21806
This commit migrates the "Manage User" footer buttons to the user
profile modal. We made this change because we don't want the buttons
to scroll with the content; instead, we want them to be sticky at
the bottom at all times. Therefore, we moved the buttons to the user
profile modal.
This commit migrates the "manage user" modal to the "Full Profile"
modal. Refactored the show_edit_user_info_modal function since
earlier, we used to have a separate "Manage User" modal.
Consequently, we checked if we were coming from the
user_info_popover and then built the dialog widget accordingly.
However, with this new change, we no longer need to build the
dialog widget. Therefore, removed that part and now just pass
the container of the 'user profile modal' to get the content.
Previously, for deactivation, we used to have a separate dialog
widget. But now, since we have a dedicated function to handle
this case, refactored the deactivation code to use the
'confirm_deactivation' function.
Additionally, created two new functions to handle the loading
spinner. Since we will need these functions in the future for
the "Manage Bot" modal, we marked them as exported.
"Since we do not want to show the 'Manage User' tab to the user
looking at their own profile, in the 'can_manage_user' function
that we use to render the 'Manage User' tab, we check if the user
profile popover belongs to the same user. If it does, we set it to
'false' instead of 'true,' ensuring that the 'Manage User' tab is
not visible.
Added a new tab in the user profile modal 'manage user'.
Fixes: #21806
Rearranged some code to align with our current patterns and improve
readability. Renamed `show_user_group_info_popover`. No functional
changes in this commit.
This is a preparatory commit before we migrate `user_group_popover`
from Bootstrap to Tippy library.
The previous implementation was weirdly sharing the logic around
`current_message_info_popover_elem` with the user info popovers based
on a message; very likely an unfortunate latent bug caused by
copy/paste.
To address that, we need to add dedicated functions like
get_user_group_popover_items to avoid breaking keyboard navigation
with this extraction.
With the previous commits, we have now implemented the subscribe
widget with a separate heading. However, the font size and the gap
of both the heading of the widget and the streams list look bad,
so this commit fixes that.
Since the heading of both the widget and the list have the same CSS,
instead of duplicating it, we used the same class for both and
reduced the font size.
This commit adds a reset function for the subscribe widget so that
whenever someone subscribes to a stream from the dropdown, after
the subscription, the dropdown will return to its initial state
with no stream selected. Additionally, it will display a label with
the subscribe button disabled and a tooltip.
This commit adds a tippy tooltip to the subscribe button in
the user profile. We show this tooltip only when there is no
stream selected and the button is disabled. However, on any
change, we enable the button and hide the tooltip.
This commit adds a subscription widget to the user profile,
including the logic to prevent non-admin users from seeing the
subscription widget of other users. Additionally, as it is not
possible to subscribe generic bots to streams, and the user should
not be a deactivated user, we check for these conditions before
displaying the subscription widget.
To ensure that the alert for both subscribing and unsubscribing
appears on top of the subscribe widget, changed the location of
the alert to be displayed at the top.
Additionally, considering that no stream will be initially selected,
we have made the decision to disable the subscribe button. Once the
user selects a stream, we will enable the subscribe button
accordingly.
Changed the add_user_ids_to_stream function inside subscriber_api.js
to support self subscribe also, so that we don't have to duplicate the
logic in user_profile.js
Created a separate file for the subscribe widget called
user_profile_subscribe_widget.hbs.
Fixes: #18883
The closest($stream_row) logic is unnecessary, and worth cleaning up
because we'll be adding other calls from places that don't have a
stream row object.
narrow is a term that is intended to only apply to a message feed
view; it comes from "narrowing the set of messages you're looking
at from the All messages" so switching it to something different
makes sense.
Adds a section to the demo organizations help center article about
configuring an email and password for demo organization owners.
For demo organization warning banners about needing to configure
an email, add a link to the new section in the help article.
Also, adds a related articles section to the help center article,
and updates the current draft text for changes in how the demo
organization feature is being implemented.
To reduce extra work for translators, make text for warning banners
and tooltips in demo organizations when the organization owner has
not configured an email address consistent.
Rename existing shortened references to demo organizations, like
`is_demo_org` or `demo-org-warning`, that have been used in the
codebase so far and replace them to be like the `models.py`
variable: `Realm.demo_organization_scheduled_deletion_date`.
The callers of function `upload_widget.build_direct_upload_widget` always
have a defined value for the parameter `max_file_upload_size`, hence we
should just remove the default value for this parameter here.
As stated in the deactivate function comments, it should be called
via `browser_history.go_to_location` so that all the correct
functions are called like recent view being hidden.
This fixes a bug where searching for nothing results in activating
all messages narrow without hiding recent view. Now, all messages
should be activated as expected.