Fixes#25414.
We add Attachment.scheduled_messages relation to track ScheduledMessages
which reference the attachment.
The import bits can be done after merging this, by updating #25345.
In the "mentions" test, an additional unread message with the type
"private" and directly mentioning me has been added. This test case
checks for the scenario when the stream_id is null during the
reverse_lookup, which would have caused the test to fail before the
bug fix was implemented which now passes after the fix is applied.
This commit fixes the issue where the "Add a new emoji" button
was being displayed for users who did not have the necessary
permissions to add emojis. With this fix, the button will no
longer appear for unauthorized users, aligning with the
current behavior for bots and user groups.
Fixes#24918.
We now return "first_unread" as anchor from get_backfill_anchor in
case when the message list is empty instead of throwing an error.
Doing this, would just result in fetching the messages normally like
it happens when a user narrows to a stream by clicking on it from
sidebar.
This also helps us handling the case, when all messages in the
current stream narrow are removed due to moving them, by fetching
the other messages from server for that stream narrow.
Previously, if the client recieved an "update_messages" event with
"message_id" not present locally, then the event was completely
ignored. But, this can happen when moving messages especially
when doing a partial move due to time limit error.
This commit updates the code to have the code which requires the
message to be present locally run only if it is present instead
of just ignoring the event completely such that the updates for
moving the messages can be done.
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.)
Mateusz Mandera
Aman Agrawal
Karl Stolley
Trident Pancake
Hardik Dharmani
Akarsh Jain
Tim Abbott
Sahil Batra
Alex Vandiver
Daniil Fadeev
Lauryn Menard
Alya Abbott
sbansal1999
Anders Kaseorg