This commit ensures that user-locale and 24-hour preferences are
respected in the message-scheduling modal. It also simplifies the
translation of text strings in the scheduling modal.
Available scheduling options and their time values, including whether
the options are allowed, are now calculated every time a user opens
the scheduling modal.
In order to achieve those things, additional interrelated fixes here
accomplish the following:
1. Modal-scheduling opts now have data- attributes containing
timestamps for the time a message will be scheduled to send.
2. With those timestamps in place, the logic for setting the
scheduled send-time is simplified.
3. There are no more `send_later_xxx` global variables in the
`schedule_send` module.
Fixes#25403.
Previously, we've been assuming that when a user narrows to a topic
or recipient, that the target message would be marked as read in
resulting view. This is no longer a safe assumption because a user
can have their personal display settings to never mark messages as
read, even in conversation views.
Removes the call to `unread_ops.notify_server_message_read` in
both `narrow.by_topic` and `narrow.by_recipient` in the web app.
pg_upgradecluster will start the cluster if the old cluster was
started before it ran, or if there are post-upgrade scripts to run.
Because neither of those are fully under our control, only attempt to
start the new cluster if it isn't already.
Fixes#25401
We no longer try to narrow to the recipient of the scheduled
message when processing `Undo`. This does not affect editing
via scheduled messages overlay.
This commit extracts date-based logic from the popover menu file and
puts it in with the scheduled-messages logic.
The aim is for greater testability, with some initial tests now
presented on the date-based logic.
I can't see any reason why it'd make sense to call a bunch of
functions designed to process newly arrived messages with an empty
list of messages to handle a 400 error from the server.
As best I can tell, the only part of this that was useful is showing
the appropriate empty narrow message.
Containing all the message_fetch logic for #connection-error inside
load_messages is considerably more readable, and will help with being
able to clean up the process_result hack.
Previously, when backfilling in a stream narrow (the main situation
where _items != _all_items), we would double-fetch any muted messages
older than the oldest message not hidden due to topic or user muting.
We change the all_messages fetch to use this function even though it
doesn't matter, just for clarity about the intent.
Since this bug could have prevented making progress fixes a
theoretical bug that could result in the client trying to fetch
messages for a given narrow indefinitely.
The core logic for deciding whether newly fetched messages should be
prepended, appended, or inserted between existing messages was wrong
in the case that the message list was only visibly empty, but its
data structures contained some muted messages.
In particular, the _all_data data structure would end up having items
appended when they should be prepended; while this would eventually be
corrected if a rerender triggered a sort, it was a data corruption
with unknown secondary consequences, and in particular would mess up
any logic correctly using the first/last elements in _all_data.
Fix this by doing all of the logic using functions accessing
_all_items. While doing so, we simplify the logic by removing the
unnecessary special case for empty message lists, including the
parallel filter_incoming function, which added extra complexity that
should always produce the same result.
The message_list.empty helper wraps this method, and thus is corrected
as well.
In an upcoming commit, we will fix a bug that caused the
message_list_data system to append rather than prepending when
previously all the messages in a message list were hidden due to
topic/user muting.
This function will allow us to adjust the codebase to write what it
means semantically -- whether a check is for the message list being
visibly empty, or completely empty.
In this commit, we leave the .empty() method incorrect, because
several other adjustments need to be made atomically with fixing it.
There two situations where we might add messages to a previously empty
message list. The first is when a new message comes in; in that case,
the previous logic of just selecting the first message would work.
But in the case where we're instead adding a bunch of (previously
read) messages via a backfill API request, which can occur in a few
cases, including a stream narrow where all the topics with recent
messages are muted, we should use our standard rules to pick a message
to select, namely the first unread message (if any) or last message if
none are unread.
Private messages with mentions are included in
unread_mentions_counter, but of course don't have a stream ID, so
should be skipped when calculating which streams contain unread
mentions.
This code has always been wrong, it put `undefined` in the set of
stream IDs with unread mentions.
What changed recently is that in
98162b7a3a, we started using the
`stream_id` to do an additional lookup in the unmuted version of the
function, and doing that lookup with `undefined` threw an exception.
Apparently some past refactor caused the animation for new mentions to
be triggered when initialization the app.
(This seems pretty clearly unintentional: A user loading the app
doesn't need their attention specifically drawn to the @-mentions view
in the same way that a user who is using the app and receives a
mention right now does.)
This was doing bulk_create in a loop for each realm, which is too slow
on very large servers. Just do a single bulk_create with a reasonable
batch_size at the end.
Deduplicated logic for calculating unread message counts and
stream counts for subscribed streams by refactoring `get_counts` to
use `get_stream_count` function for calculating unread message counts
for each subscribed stream.
Fixes#24641
When the user clicks on a link which has `stopPropagation`
and doesn't trigger `scroll`, then we don't hide any existing
popovers if the element being clicked doesn't hide popovers
explicitly.
To fix this, we hide all popovers on change in hash which makes sense
on its own given how we use hashes.
This commit introduces structures and logic to hide the Scheduled
messages item from the left sidebar if there are no messages
scheduled to be sent.
Test coverage has been added for counts and visibility, too.
Fixes: #25101
This commit introduces logic to present a message count with the
Scheduled messages item in the left sidebar.
The count is present on the initial load, and is updated as a user
adds or removes scheduled messages.
The click handlers for compose banners, many of which can appear both
in the message editing code path and above the compose box, were
incorrectly scoped to only the #compose_banners container.
These click handlers were all overly specific; they already have a
very unique selector in the form of things like
.compose_banner_close_button, and more shouldn't be necessary.
Added hotkey hint to Narrow to stream/topic/DM tooltips by creating
new tippy for `tippy-narrow-tooltip` with LONG_HOVER_DELAY which
appends `S` hotkey to the existing tippy content set by
data-tippy-content attribute on the element.
Using this approach instead of a <template> with
data-tooltip-template-id avoids issues with context, where
{display_recipient}/{topic}/{display_reply_to} inside <template>
would always show the same stream/topic name regardless of the
actual stream/topic being hovered over.
We move "Allow message content in message notification emails" setting
from "Other settings" subsection to "Automated messages and emails"
subsection.
Fixes#25339.
Tim Abbott
Alex Vandiver
Karl Stolley
Daniil Fadeev
Lauryn Menard
Alya Abbott
Aman Agrawal
sbansal1999
Anders Kaseorg
Mateusz Mandera
Hardik Dharmani
Sahil Batra