This parameter is unused for Zulip avatars, and results in a smaller
(pixel-wise) Gravatar than we use for Zulip "small" avatars. Omitting
the `s=50` parameter results in a 80x80 image, which is closer to the
100x100 image that Zulip thumbnails avatars to. Ironically, using the
default (larger) Gravatar dimensions also results in _smaller_
responses (in bytes) from Gravatar.
We are using `.val` to set compose box content which is very fast vs
`setFieldText` which is very slow due to it doing a lot of
forced repaints. The major downside of using `val` here is that
user will not able to perform `undo` operation on this which doesn't
seem something user would want to do here.
Note that this effects compose content restored from drafts,
scheduled messages and on reload.
To enhance the readability and operand handling of the
get_custom_profile_field_data function in user_profile, avoid the
unnecessary passing of objects inget_external_account_link.
Instead, pass only the required field_data and value.
Also remove the unnecessary field_type key stored in profile_field in
get_custom_profile_field_data data function.
On clicking the "Edit your profile" option in the user popover,
profile section is opened directly for narrow screens as well
instead of just showing the left panel list of sections.
For narrow screens, we only show left side panel list on
opening the overlay. Previously, we showed the right section
if the overlay was closed with a right-side section opened.
Currently if the settings overlay is opened on narrow screen,
where only left side panels are shown, and then the screen
width is increased, the right side shows "Profile" and
"Account and privacy" sections of personal settings together
everytime.
This fixes it to show the last opened section or the first
section or the section used in url.
Have one inbox row and focus on it. Mark the message as read in
another tab. Press `r` in the first tab will return an error as
the row_focus didn't change but there is no present. So, we
fix it by updating the row_focus if it can get out of bounds
when updating inbox view.
This commit is part of a bigger project to remove custom logic in
the input_pill module. This commit move us away from a world where
we have a `display_value` that's used as identifying information
for a pill as well as for what we display to the user. Now individual
widgets can configure how they come up with a display value based
on the data of that type of pill.
Note: The change in the stream pill test for setting subscribers
for denmark is fixing an issue that wasn't discoverable before.
There always should have been three subscribers.
We no longer need to do `robust_url_decode` because we're
creating the display value ourselves, whereas previously
we were using `Filter.unparse` which does encoding.
By using a custom `generate_pill_html`, we can remove the
`has_stream` logic in `input_pill`, as part of a wider effort
to remove custom pill logic in `input_pill`.
This is part of a larger effort to refactor input_pill to
remove custom logic and move it into relevant modules.
This commit completely removes group_id from all modules, but
there's another module that uses stream that must be refactored
before that can be removed from input_pill.
This is part of a larger project to move custom
logic out of input_pill. The `generate_pill_html`
function will be used for other modules in upcoming
commits.
Function `message_helper.process_new_message` takes a
`RawMessage` and throws out `Message`. But here we are
passing it an already processed msg of type `Message`.
This is completely type unsafe. Since our purpose here is to
replace our old message object with a latest copy from
`message_store`.
We can do this directly without calling `process_new_message`.
Because the compose-box resize logic is tied to the size of the
textarea, it's possible when resizing in preview mode that the
state of the compose box is not properly tracked. That's because
the height logic in `autosize_message_content` assumes a visible
textarea.
However, because both the textarea and the message preview area
occupy the same named grid area (`message-content`), and because
the preview area comes after the textarea in the DOM, when visible,
the preview area will automatically cover (and be sized to) the
textarea. And because the textarea remains observable in the DOM,
the compose box will obey the same expansion logic in preview mode
as it does in edit mode.
This check been present since
466beef6fe, but it seems unnecessary in
that the main logic handles there being 0 channels just fine, that's a
rare case (so not a useful optimization), and importantly, not calling
stream_list_sort.sort_groups for that transition resulted in
`stream_list_sort` having stale data structures, resulting in
exceptions if one tried to open the CHANNELS filter widget in the
newly-no-channels state.
When the caret in textarea is around the right end of the screen,
typeahead can overflow the window. To fix it, we use tippy's
mechanism to keep the tooltip inside the visible boundary.
Scroll to bottom button is visible for a few ms when switching
narrow to Inbox / Recent view while scrolling in message feed.
While we can end the transition faster to completely avoid the issue
for now but this seems like a more permanent and simpler fix
than to fiddle with CSS.
Here we want to rerender the current narrow after receiving an
event which moves messages. We have mechanisms to keep using
the cached list if we are narrowing to the same narrow which
we want to avoid in this case.
This reworks canonical_url_of_media to work with HTMLMediaElement,
making it possible to do cross-browser inspection of media sources.
(Firefox and Chrome disagree on whether to return the "href"
attribute as the path in the source, or a full URL).
Additionally, we ensure non-empty cache keys on media so
unexpected results from the DOM do not get cached.
Co-Authored-By: Alex Vandiver <alexmv@zulip.com>
Co-Authored-By: roanster007 <rohan.gudimetla07@gmail.com>
Using different punctuation for the aria-label from the tooltip is
silly. Additionally, we don't need to repeat the channel name in
aria-label; it essentially will never be seen and the message list
copy of getting the channel name was buggy.
Tested by deleting a DM and navigating to recent view. No error
is thrown and dm row is correctly placed.
Co-authored-by: Tim Abbott <tabbott@zulip.com>
Earlier tooltip info for the default topic menu notification option
had static string to display.
This commit changes the string info and includes channel name and its
corresponding privacy icon to display in the tooltip.
Earlier, the `Add Channel` button was being focused even after the
modal was open, causing multiple modals to open on pressing enter
repeatedly.
This commit fixes the issue by removing the focus from the `Add
Channel` button after the modal is open by focusing the dropdown on the
modal.
Earlier the focus remained on the button to open the modal,
causing multiple modals to open on pressing enter repeatedly.
This commit fixes the issue by removing the focus from the button
by focusing on the first input field of the modal.
When moving message while compose box has content, stream was not
updated to the new stream if it was changed.
Tested by moving message with stream changed and with / without topic
changed.
This commit makes pasting formatted text a two-step process:
- Insert unformatted text
- Insert formatting
This way, undo (Ctrl+Z) will restore the original pre-formatting
syntax.
This is the same as the approach taken with
auto-formatting in #29302.
Fixes#31061
This commit fixes the overflowing issue for long bot owner names in the
user card popover, and also repositions the bot owner user card popover
to align with the bot owner name on the bot user card popover.
The `.popover-menu-user-avatar` selector being used to replace the small
avatar with the medium avatar was a broad selector, which also targeted
the bot's avatar when the bot owner's user card was opened. This commit
fixes this bug by scoping the selector to the current popover instance.
I'm not aware of us using any of these; we don't generate the class
names involved, and we're not using `uppy.use` on any of their UI
components.
I confirmed that the only use of an Uppy UI component was the progress
bar, which was stopped using in
b01ac3623f.
We previously did not allow users to deactivate themselves from users
list to avoid users deactivating themselves accidentally. But we now
show a confirmation modal before deactivating, so it is fine to allow
it.
When the user card is displayed via right sidebar, the reference
can be lost due to it being updated or hidden on window resize.
To fix it, we show user card as an overlay when we cannot find
the reference.
Another solution would have been to relocate the reference and
update it for the popover but that is not naturally supported by
tippy once the popover has been displayed.
As a follow-up to the commit f124ef931, which deals with the keyboard
focus when opened via the keyboard shortcut `U`, this commit ensures
that when the user card is opened via the mouse, and the first
navigational key is pressed, the focus is on the first menu option
instead of the other tabbable elements which can be distracting.
Previously, clicking on "view user profile" in the user card popover
would open up the profile as an overlay, changing the hash, and
closing other already opened overlays when opened.
This commit would modify it to behave as a modal rather when
an overlay is already open in the background, thus preventing
the hash change, and allowing the background overlays to exist
when it is opened.
Fixes#30481
Fixes#30851.
Since there can be multiple messages being edited at once, with a
possibility for them to be out of the DOM, we use
compose_state.get_last_focused_compose_type_input to determine which
message edit to toggle the preview mode on.
We keep the compose box preview toggle behaviour more or less the same,
where we do not check whether the compose box was last focused or not if
there are no eligible message edit boxes and the compose box is open.
This behaviour works well for compose box since there's always one
possible compose box at a time compared to multiple message edit boxes.
One thing to note behaviour wise is that if you have 1 message edit
box open and you shift the focus to compose box, and then close the
compose box, `Alt + P` will not work until the focus is brought back again to
the message edit box.
We want to able to use the clear_preview_area in other places than
click_handlers and that's why it has been moved to message_edit.js.
The name was chosen to be consistent with a similar function in
compose.js.
We want to use render_and_show_preview in message_edit, but that will
cause a dependency cycle because of message_events. In order to avoid
the dependency cycle, the function has been moved to compose_ui and
relevant types have been added.
This commit does not audit the existing function for improvements, just
moves it around and adds types.
The `msg` and `result` are same as the other files (e.g.
activity.test.js) with success responses.
This adds the `LONG_HOVER_DELAY` delay to the user card tooltips, which
prevent the tooltips from becoming distracting when the user is just
navigating the popover.
When the user card is opened via the keyboard shortcut `U`, the initial
focus should be on the first popover menu option, rather than the copy
buttons or the custom profile field links which can be distracting due
to the presence of tooltips on them.
Fixes part of #31027.
Changing the button text of one-time modals to introduce the recent and
inbox view to say "Got it" rather than "Continue" helps reinforce the
vocabulary we're using "Got it" = dismiss one-time content forever.
The previous logic did not properly account for the fact that in muted
channels, unmuted/followed topics are sorted above normal topics.
Rather than trying to reproduce that logic, we just call the function
for computing the topics in the left sidebar, and pull off the top
topic.
Earlier the focus was not being set to the modal when it was opened.
This was because `is_in_focus` checks if `modals.any_active` which
checks `$(".micromodal").hasClass("modal--open")`.
But when `is_in_focus` is called
`$(".micromodal").hasClass("modal--opening")`.
This commit fixes the issue by creating a function
`is_active_or_animating` which checks if the modal has the class
`modal--open` or `modal--opening`.
Earlier, when the user deactivation modal was open, the focus was not
set on the modal. This commit fixes that by setting
`focus_submit_on_open` to `true` in the modal options.
Previously animated images were automatically played in the
message feed of the web app.
Now that we have still thumbnails available for them, we can add a new
personal setting, "web_animate_image_previews", which controls how the
animated images would be played in the web app message feed -- always
played, on hover, or only in the image viewer.
Fixes#31016.
There was a bug when stream_id field was being passed as NaN when user
tried to edit topic of a message if the user did not had permission
to edit the channel.
This commit fixes it to not pass stream_id field in such cases because
channel cannot be changed.
Fixes#30992.
When a user changed an email, we updated the compose and narrow state
before updating that person's email in `people_dict`. This raised a
warning in `get_direct_message_permission_hints` when using
`emails_strings_to_user_ids_string` since that person's email wasn't
updated in `people_dict` by then.
We just changed the order of update so that the email is updated in
`people_dict` before we update compose and narrow state.
After navigating to a `near` narrow, user is likely to press back
to go back to previous selected message. To support this, we have
to select `then_select_id` without rerender, if we can.
Tested by using breakpoints with `near` links to check if the
correct code is being executed.
This moves the cache key for parse_media_data to being the "canonical"
image URL, not the displayed `img src`. We may not even have the `img
src`, if the thumbnail has not yet been generated.
We use different text for guest users, specifying that they can
only search in channels they can view.
The issue description suggests the same for spectators, but
we already use different text for them.
The search-operators help overlay is also updated with the same.
Fixes#30902
Previously, if you typed "channel: rome" you'd see a result for
both channel "rome" and a second one for "Rome". This commit
deduplicates that by comparing for duplicates without case
sensitivity.
Note that if you fully type "channel: rome" you'll see the
result with a lowercase R instead of uppercase. It would
be a bit involved to change this, so I'm leaving that as
something to address in the future.
This commit removes the popover from the "+" button shown in the closed
compose UI at mobile widths, and instead performs compose actions
directly on-click. The "+" button now opens the compose box with the
channel picker open (even if the user is in a topic or channel view).
This reduces the number of clicks required to start a new message from
the closed compose UI in mobile views, and makes the behavior more
consistent across all the views.
Fixes#30634.
The `update_new_direct_message_button` function sets the text for the
new DM button to "New direct message" on every update cycle, which makes
no difference since the button starts with that text and never changes.
This adds the "New direct message" button back in the closed compose UI
for DMs view, to make the closed compose UI consistent across the app.
Since the closed compose UI is always visible, and one that is likely
to be used frequently, it makes sense to have the same UI across all
the views to avoid the mental overhead of figuring out how to compose
a message in different views.
This keeps the first item focused when user uses keyboard.
User can still move the focused item using mouse and click to select it.
Highlighting an item via mouse and then pressing enter would select
the highlighted item.
We change the code to update the visibility of information
density setting inputs only on successful completion of
request and not on receiving events.
Visibility of inputs is not being live updated on receiving
events because that leads to flashing of inputs when deselecting
the "Compact mode" checkbox due to the data being sent in
different events and data with the client being different for
time till the all events are received.
Bug:
A tooltip appears on hovering over a control button in the
message edit form. Now when the form was closed either using
Esc key (cancel) or Enter / Ctrl + Enter (save), the tooltip
didn't disappear. This resulted in a random tooltip visible
in the message list view.
Fix:
Since tippyjs doesn't hide tooltip even after the element is
hidden we need to explicitly hide the tooltip in those cases.
See https://github.com/atomiks/tippyjs/issues/938
This commit fixes the above mentioned bug by explicitly hiding
the tooltip instance.
Earlier the `generate integration url` button (fa-link) was still in
focus even after opening the modal.
This caused the modal to open multiple times when the user pressed the
enter key. This commit fixes that issue by focusing on the input
dropdown when the modal is opened.
Earlier the `Add a new emoji` button was still in focus even
after opening the modal. This caused the modal to open multiple times
when the user pressed the enter key. This commit fixes that issue by
focusing on the input field when the modal is opened.
Earlier the `edit` button was still in focus even after opening the
modal. This caused the modal to open multiple times when the user
pressed the enter key. This commit fixes that issue by placing the
carat at the end of the first input field when the modal is opened.
Earlier the `change your password` button was still in focus even
after opening the modal. This caused the modal to open multiple times
when the user pressed the enter key. This commit fixes that issue by
focusing on the input field when the modal is opened.
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>
While using the pill in `stream_create`, it was noticed that deactivated
users were also part of the user_ids returned by the user_group_pill,
which we do not want to do.
This pill is used in two areas: compose box and stream create/edit.
This commit will only affect stream create/edit since compose box was
just using the typeahead data from user_group_pill and nothing else.
Stream and user pill handle inactive users already, so no change is
needed there.
Fixes#30690.
Before this, we were adding all users to subscriber list without adding
any pill. But, since we want pills to be the source of truth for adding
the subscribers, we will just add the `role:everyone` pill from now on
whenever `Add all users` is clicked.
While we can just directly call `pill_widget.appendValue` in
`stream_create_subscribers`, it's better to expose an API from
`add_subscribers_pill` and use that. This lets us control how appending
an item would work for subscriber pill in a single place.
We list all the members of a group including recursive subgroup members
in the user group popover.
We also add another change in this commit to show `Everyone` if the
group name is `role:everyone` by using
`user_groups.get_display_group_name`.
For system groups, the directive is that we should use the description
as the display name. But in case of `role:everyone`, the description is
`Admins, moderators, members and guests`, while for the
`user_group_pill`, we want to display a simpler and succinct message:
`Everyone`. We've only hardcoded this for user_group_pill since we don't
want to display the name as `Everyone` anywhere else yet.
We've also exposed a method called `get_display_group_name` which will
be used in later commits to get the group display name.
While the support to include all members of a subgroup is needed only in
the `stream_create` context for now, we have added the support for
subgroups to `user_group_pill` for all cases. We have done this because
that is still going to be the correct behaviour if we add similar
support to other pill inputs.
In terms of calculating and populating the recursive member list, it was
decided not to do it when initializing the user_groups data. One reason
for that was it would introduce a lot more complexity when adding or
removing members from any of the subgroups to keep the recursive member
list updated. Keeping in line with the general pattern of calculating
recursive subgroups on the fly too, it was decided to calculate the
recursive list of members on the fly too.
Also changes the `get_group_ids` tests to make sure that subgroup ids
are not part of the result of `get_group_ids`. Since it is used to
calculated taken_groups, we don't want to filter out subgroups as part
of taken_groups and their typeahead should still be visible.
This function goes through all subgroups recursively and returns the
resultant set of the members of those subgroups in addition to the
members of our target_group.
This function is required in order to add the `everyone` pill to create
channel flow.
For the tests written in this commit, it uses the same pattern as the
`get_recursive_subgroups` test.
`is_user_in_group` could have been technically refactored to use
`get_recursive_group_members`, but since the former returns early for
direct members, I've let it be for now.
Transforming valid stream/topic urls to the #**stream>topic**
syntax.
- A valid url contains a stream and optionally a topic
but nothing else, and in that order.
It must belong to the same origin as the Zulip server.
The stream id present in the pasted url should
correspond to an actual stream in the current
server.
- `near` links are not transformed.
- Use-mention distinction is respected by
not transforming a valid url if pasted using
`Ctrl+Shift+V`.
- No transformation occurs inside a code block.
- On pressing `Ctrl+Z` after pasting,
the actual pasted link is restored.
- No transformation occurs if the url is pasted over an
existing url in a markdown link syntax.
- No transformation occurs if the stream or topic name
contained in the pasted url is known to produce broken
stream/topic syntax links (as per #30071).
Fixes#29136
Earlier in right sidebar user count, it would show less user count
when a bot was present as a recipient in the conversation. Since the
sidebar shows active human users only, user count should not
consider bots in the conversation.
This commit fixes the behaviour by adding all the subtracted bots
in from user count.
The extra undefined parameter appears to be a bug introduced in
5142f1279a45d00320904b369b092f0c9c116b90; when the show_as_overlay
parmater was dropped, the other callers to show_user_card_popover did
not have their extra argument removed.
This had the effect of not setting initial keyboard focus when opening
the popover.
Previously, the tooltip for the status clear button was scoped to only
the personal menu popover. This commit moves that logic to `tippyjs.ts`
and adds support for the status clear button in the user card popover.
As a follow-up to the user card popover redesign, this commit removes
the unused code and styles from the user card popover.
- Removed tooltip logic for user name and user type, since we now
display them in full without any ellipses.
- Removed unused css whose class names are no longer used in the
user card popover.
- Removed additional styling needed to handle font awesome and zulip
custom icons, used in the older design.
Previously, when the email was successfully copied via the email copy
button, the email in the user card popover was replaced with a "Email
copied!" message.
This commit replaces this behavior with a more subtle approach, where
only the tooltip of the email copy button changes to "Copied!".
This commit extends the user card popover redesign to the case where
the guest is not allowed access to view some of the other users'
profiles due to a change in the
"Who can view all other users in the organization" permission.
Fixes#27338.
Varun Singh
evykassirer
Alex Vandiver
Aman Agrawal
afeefuddin
Karl Stolley
Sahil Batra
Anders Kaseorg
Tim Abbott
Shubham Padia
roanster007
Pratik Chanda
Kenneth Rodrigues
Kislay Verma
Sayam Samal
Prakhar Pratyush
Vector73
Sanchit Sharma
sujal shah
Prakhar Pratyush
adnan-td