We now try harder to find the first unread message in an
upcoming narrow, which has the user-visible effect that we
select the unread message before waiting for search results.
Before this change, we only applied this logic to searches
that were things like exactly stream/topic or exactly is-private.
Now we will also handle things like stream/topic/sender. For
the stream/topic piece we look up candidate unread ids using
the steam/topic buckets in unread.js, but then we still filter
those messages by stream/topic/sender as we look for the first
unread id.
I renamed get_unread_ids() to _possible_unread_message_ids().
The name is deliberately verbose, since we're about
to make it have kind of unusual semantics that only make sense
for its one caller.
The outside code will continue to call get_first_unread_info().
In the tests I wrap this function in a wrapper with the more
pleasant name of "candidate_ids", since in the test there's
less worry about unwittingly exposing a kind of janky function.
This is setting up for a subsequent commit to have a smaller
diff. The current ordering of the code blocks doesn't matter,
since only one of the conditions will be true, so this won't
change any behavior. (Later commits will make the order matter.)
This reflects the fact that these are just defensive programming (we
don't expect them to ever happen) and also nicely makes these lines
not show up in our missing test coverage reports.
We only use this in the direct management command, and it involves
some autoreload process setup stuff that we probably don't want to do
in our unit tests regardless.
This system was written years ago and has been working well the whole
time, but having unit tests for it will help future developers in
understanding what the intent is.
We don't reference this anymore (it was only ever used by the Dropbox
integration, which was hardcoded-off for years before being removed in
e6833b6427)
We will use this to find the first id from a list of
message ids that matches a filter. (This will help us
during narrowing to determine whether we have at least
one good message locally, so that we can render something
useful before waiting for the server.)
This new API replaces some more specific functions that were
only recently introduced:
is_stream_only
is_stream_topic_only
is_pm_with_only
is_for_only
We use the deterministically sorted "term_type" values for
matching. (Notably "stream" will come before "topic".)
This is primarily useful for the mobile app, but could also be used to
control whether we display push-notifications related settings to
users in the web UI.
Max Nussenbaum
Aditya Bansal
Tim Abbott
Steve Howell
Raymond Akornor
Rishi Gupta