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
Since the cache is flushed when the cutoff or realm changes, the
maximum size of the cache should cap out at the number of streams in
the realm. Raise the max cache size, now that this will not simply
lead to useless cache space for smaller servers.
There is now no longer any reason to have the scheduled_email
enqueuing wait until all of the users' contexts have been generated.
Switch to returning the contexts as an iterator, and send them as we
compute them.
The query plan for fetching recent messages from the arbitrary set of
streams formed by the intersection of 30 random users can be quite
bad, and can descend into a sequential scan on `zerver_recipient`.
Worse, this work of pulling recent messages out is redone if the
stream appears in the next batch of 30 users.
Instead, pull the recent messages for a stream on a one-by-one basis,
but cache them in an in-memory cache. Since digests are enqueued in
30-user batches but still one-realm-at-a-time, work will be saved both
in terms of faster query plans whose results can also be reused across
batches.
This requires that we pull the stream-id to stream-name mapping for
_all_ streams in the realm at once, but that is well-indexed and
unlikely to cause performance issues -- in fact, it may be faster
than pulling a random subset of the streams in the realm.
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.
We already allowed reruns for failing tests, and this adds
the ability to rerun tests that succeeded as well, which is
helpful for debugging flaky tests.
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.
Lalit
palashb01
Anders Kaseorg
yogesh sirsat
Aman Agrawal
Alex Vandiver
Vector73
David Rosa
evykassirer
N-Shar-ma
Daniil Fadeev
Tim Abbott
Karl Stolley