Fixes#23406.
Fixes#14053.
This also uses the new alert banner system.
It is not clear if we want to scroll user to the end of the narrow
after this update is complete. There is a "scroll to bottom" button
for users who want to be placed at the end of the narrow but there
is no reverse option for users who don't. So, maybe not changing
the scroll position is preferred especially since we now use
banners for the update where a user could have been reading something
while we were updating the message flags in the background.
We do not handle the case of `mark as read` and `mark as unread`
both running in batches at the same (This is a somewhat rare case
given the high cap on `NUM_OF_MESSAGES_UPDATED_PER_BATCH` but
possible.).
`unread.declare_bankruptcy` is no longer used in the code but
we keep it since it is used extensively in tests.
Previous algorithm was not correct if we didn't have full data for
the current narrow loaded from the server. #23512 adds the support
to mark messages in a narrow unread after a give message_id.
Added a new alert banner to indicate loading and success states of
an ongoing request. This is useful when requests can take a long
time to complete.
Doing rapid pace mark-as-unread in the Zulip web application, one
observed assertion failures showing that the server would send an
event containing multiple message IDs but only one of the messages
present in the message_details side data structure.
The cause of this was the "virtual events" compression system; two
flags/remove/read events were being combined by simply concatenating
the lists of events, without any attempt to merge the
`message_details` field on those objects.
The immediate fix is to disable virtual events compression for this
event class, but it's not unlikely we'll need to just eliminate the
virtual_events system entirely, because it seems difficult to make it
soundly handle a message whose state for a given flag changes back and
forth while the client is offline.
But we'll leave that for later, since removing that optimization
deserves more discussion than fixing this event corruption bug.
The naive solution #23465 creates situations where the same user can have
multiple reactions as the base emojis are not unique, e.g. +1::skin2
and +1::skin4 would both reduce to +1 but the userlists are separate.
This solution handles the reduction, merges the same-base reactions,
and deduplicates the userlist.
Co-authored-by: Alex Vandiver <alexmv@zulip.com>
Co-authored-by: rht <rhtbot@protonmail.com>
Following b563fdc537, the z-index of the
compose box (2) tied with that of unread date dividers within a topic;
this could lead to the dividers incorrectly appearing on top of the
compose box.
We don't have other elements that can overlap with compose with a
z-index between 2 and 4, so just increase it to 4.
This commit removes comments related to stream-admin option from
wildcard_mention_allowed.
We have already removed stream-admin option from wildcard mention
policy setting in 83383090f9 since we are no longer planning to
implement stream admin feature and instead are working on new
permissions model based on user groups.
return inside finally blocks causes exceptions to be silenced.
Although these blocks follow blanket ‘except Exception’ handlers, they
do not seem to have a goal of silencing BaseException and exceptions
thrown by the exception handler, so rewrite them to avoid it.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
We do not want to import any of our modules into this file, so
it has an independent implementation of the fix for #22062. Also,
using -13 as a keyCode helps avoid having to make changes to all
the comparisons with e.keyCode that the module relies on.
Both of these compatibility blocks can be deleted, since you can't
upgrade directly to any supported release from the versions where the
old event formats would be used.
This solves the problem that resolving a topic with a long name (>60
characters) will cause the topic name to be truncated, and thus the edit
message code path thinks that the topic is being moved in addition to
being resolved.
We store the pre-truncation topic and use it to check against the
original topic when determining whether a topic is being moved while
getting (un)resovled or not.
Fixes#23482
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
We intended to send both the "topic was resolved" and the "topic was
moved here" notification when resolving and moving a topic at the same
time in #22312.
The previous implementation did not work as expected and it was only
sending the "topic was moved here" notification.
This removes the check for old_topic and new_topic that have
RESOLVED_TOPIC_PREFIX stripped in maybe_send_resolve_notifications, so
that the notification will be sent regardless if the topic name without
the prefix stays the same or not.
Note that weird topic handling ("✔ ✔✔ some topic") in the comments
was added in e231a03eff is unaffected. In case of confusion, the lstrip
check is not essential to detecting topic being unresolved/resolved.
As we mainly have that handled in the latter part of the helper.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
Tim Abbott
Aman Agrawal
rht
Anders Kaseorg
Alex Vandiver
M@
Sahil Batra
Rohitt Vashishtha
Hari Prashant Bhimaraju
Zixuan James Li