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`.
Added `result_` prefix to differentiate it from upcoming `message_ids`
parameter to the API request. Also, this is final `message_ids` that
we will fetch the messages for. So, a `result` prefix makes sense here.
This flake was happening since `wait_for_fully_processed_message`
only checks if the `star` icon is displayed on the message but
doesn't check for current narrow or waits for the narrow to
change.
Since narrow is changed to the message narrow after sending a
message. If we don't wait for narrow to change, this narrow change
can make the `get_current_msg_list_id` call return true for the
wrong narrow change. Which causes message list id of the wrong
message list to be returned and hence we cannot locate this
message list id.
To fix it, we check if sending this message will cause a narrow
change and if true, we wait for the narrow to change before
checking if the message is visible.
Anders Kaseorg
Lauryn Menard
Karl Stolley
Sayam Samal
Tim Abbott
Mateusz Mandera
evykassirer
Alex Vandiver
Sahil Batra
Aman Agrawal
Prakhar Pratyush