We show a confirmation dialog explaining the "resolve topics"
feature when the user marks a topic resolved for the first time.
If the user confirms the action, we mark the
topic resolved, else we don't.
We don't show anything the first time a topic is marked
unresolved.
Fixes#31242
This commit improves the copy codeblock button and playground button
in the codeblocks to improve their visibility, particularly when on
top of some code.
Previously, the text under these buttons was difficult to select, as the
buttons would block the selection. This commit now hides these buttons
when a user clicks on any part of the codeblock, allowing to view the
code without any distractions, as well as, allowing the user to select
any part of the code.
We previously auto-mocked this out of expediency, but that made it
impossible to test anything that uses the Zod schemata in the same
module.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Document the keyboard shortcut for sending a message and
inserting a line that can be used at all times, and then
describe the keyboard shortcuts for those actions that
are based on the user's "Enter to send" configuration.
This commit is a follow-up of 43eebbf9c6,
and it sets `data-simplebar-tab-index="-1"` on the remaining popovers.
This prevents the simplebar container from taking focus while trying to
navigate the popovers via the keyboard, thus fixing the bug where the
user had to click the down key twice before reaching the first
focus-able popover menu option.
Limiting lookups by delivery_email to users with "everyone" email
visibility is overly simplistic. We can successfully do these lookups
whenever the requester has the permission to view the real email address
of the user they're looking up.
This is helpful for taking an "acting user" and getting the list of
email_address_visibility values such that the UserProfiles with those
values of the setting permit the acting user to view their
deliver_email.
This can be used for a query "all users whose delivery_email is viewable
by <requester>" in an upcoming commit.
The added code is ugly, but at least it lets us simplify some similarly
ugly logic in can_access_delivery_email.
This should work because all the events are either `change` events or
`click` events on elements without children. This change is being made
to make typescript migration easier, ecause we can type `this` more
easily than `e.target`.
This simplifies the StreamSubscription type, and parallels how we
always initialize every other property that isn’t in
NeverSubscribedStream (audible_notifications, desktop_notifications,
email_notifications, push_notifications, wildcard_mentions_notify,
color, is_muted). email_address was already optional.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Ths hardcoded documentation of which values are possible was destined
to end up inaccurate and out-of-date; and meanwhile, we do have a part
of the API that already has these data in machine-readable format.
The nginx-to-uwsig-timeout defaults to 60s, which is exactly the same
as the current "harakiri" timeout configured in uwsgi (which limits
the length a request can run before the worker is terminated). This
causes a race, where if nginx hits its 60s before uwsgi, then we
return a 504; otherwise, we get a 502.
Make the nginx-to-uwsgi timeout explicit, and shorten the "harakiri"
timeout to be explicitly less than that. Document the 60s timeout,
which all outer reverse proxies must be set to _longer than_ in order
to have proper "onion" timeouts.
This commit updates the 'notify_reaction_update' function to use
the generic 'event_recipient_ids_for_action_on_messages' function.
It helps to add hardening such that if the invariant "no usermessage
row corresponding to a message exists if the user loses access to the
message" is violated due to some bug, it has minimal user impact.
Earlier, submessage was not live-updated for users who joined
the stream after the message was sent.
This commit fixes that bug.
Also, now we use 'event_recipient_ids_for_action_on_messages'.
It helps to add hardening such that if the invariant "no usermessage
row corresponding to a message exists if the user loses access to the
message" is violated due to some bug, it has minimal user impact.
Earlier, we were sending 'delete_message' event to all active
subscribers of the stream.
We shouldn't send event to those users who don't have access
to the deleted message in a private stream with protected history.
This commit fixes that bug.
Also, now we use 'event_recipient_ids_for_action_on_messages'.
It helps to add hardening such that if the invariant "no usermessage
row corresponding to a message exists if the user loses access to the
message" is violated due to some bug, it has minimal user impact.
Fixes#31701.
This fixes a bug where when the user clicks on a near link, the
pointer doesn't shift to the `near` linked message. This can
be a confusing experience for the user.
On a fresh render of a narrow if the view doesn't scroll,
`update_sticky_recipient_headers` is not called. So, we need call
it after we have scrolled to the message we want to select.
This helps us better update the views where we don't have the
messages that were updated cached or the filter cannot be
applied locally.
Tested using browser breakpoints for search `zulip` in starred narrow
for `!filter.can_apply_locally()` and setting message_fetch
constants to single digit for `messages_to_fetch.length > 0`.
Karl Stolley
Kislay Udbhav Verma
Sayam Samal
Anders Kaseorg
Lauryn Menard
Tim Abbott
Mateusz Mandera
evykassirer
Alex Vandiver
Sahil Batra
Aman Agrawal
Prakhar Pratyush