Its selector looks like it’s missing a ‘.’, but “fixing” it breaks the
page even more, and trying to decipher this mess of event handlers
that poorly replicate what should be native behavior is making my
brain hurt.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
The commit hashes that appear in the `pull/12345/head` ref are the
ones _before_ any final rebase occurs, and as such may not match to
any commit hashes which exist in `main`.
Use the GitHub GraphQL API to pull the last "merge commit" on the PR,
which is post-rebase, and use that as the target commit when
cherry-picking. Then walk backwards from that commit, including every
sequential commit which is still associated with the PR; we do this
because during the merge, commits may be added or removed, so the PR
is not reliable in the commit count.
This commit updates the term 'stream' to 'channel' in the
section header 'Streams for Zulip users and administrators',
in /development-community'.
Also, references to this section has been updated.
This commit updates the term 'stream' to 'channel' in the section
header 'Configure who can move messages to another stream' in
'/help/restrict-moving-messages'.
Also, references to this section has been updated.
Earlier, the image used in the message actions help docs
had an alternative text that was not relevant to the image.
This commit updates the text used.
Combined feed always narrowed to the first unread id regardless
of if it was muted or not since we were not actually using the msg_id
that we found after all the hard work of doing all the checks for it.
Note: This doesn't change the occurences in the Zapier integration doc,
since they refer to pieces of the UI in Zapier, which may still be using
the "Stream" terminology.
Migration 0517 migration was already run as 0497 on `main`, but was
accidentally omitted on 8.x until this point.
Merge the 0517 migration into the migration history. It is included
as a no-op in `main` because it has already run as 0497.
Originally, we only wanted to do local echo in the current
view. However, now that we're looking at navigating the user to the
conversation that they send a new message to, it's going to be quite
common that we immediately visit a destination different from the
current view, where local echo in that different view would be
valuable.
The most interesting block was added in
af188205cb / #8989. But in
6637f2dbb7, the key logic for checking
`msg_list.data.fetch_status.has_found_newest` was duplicated in the
`add_new_messages` code path, which critically also updates
`update_expected_max_message_id` and thus may close a race with
fetching message history for a view we're being navigated to, where
the locally echoed message might fail to appear at all.
This change does come with a slight regression: If we are looking at a
search view where the filter is one that we cannot apply locally, a
newly sent message will now be locally echoed (returning the compose
box for drafting another) even though it cannot be displayed in the
current view, which means that the message will not appear in either
the compose box or the current view for the brief period before we get
a reply from the server in this scenario. This is a minor detail,
likely not worth troubling ourselves over.
Given our intent to experiment with navigating the user out of the
search view in this scenario, this is likely not important.
Co-authored-by: Tim Abbott <tabbott@zulip.com>
Anders Kaseorg
Alya Abbott
Alex Vandiver
Tim Abbott
Prakhar Pratyush
Karl Stolley
Aman Agrawal
Mateusz Mandera