We had a significant amount of code for handling what seemed to be 2
cases, but which were really just a single case (if we are trying to
narrow to a specific message ID, and we end up landing on it, restore
the previous offset; with the special case that the previous offset
might be passed in from the previous call).
This cleanup also fixes a very minor bug, where our background
auto-reload (`reload.initiate({immediate: true});` in the JS console)
would incorrectly reset the pointer position to match the a near:
message ID if that was present in the narrow.
This commit fixes a couple regression related to narrowing.
For a long time we've had bugs where we too aggressively
preserve the currrent selection on topic -> stream
re-narrows ("s" key) even when the wider narrow may
have unread messages before the selection.
Also, we recently introduced a bug so that when you used
a link from the "copy link to conversation" (aka a "near"
query), it would advance you to your first unread message
despite the near:999 specifier. (The code would work for
subsequent "near" queries once you had fetched some of
your original messages).
This commit introduces a new data structure called id_info (replacing
the select_strategy data structure) in various functions and uses that
to track all the ids of relevance.
Significantly rewritten by tabbott to handle a few extra corner cases,
and add a ton of comments explaining why it works the way it does.
Fixes#2091.
Fixes#9606.
When admin user create new private stream, widget for changing privacy
of stream doesn't render. Because we render subscription-settings
template partially on subscription-add event, so this case wasn't
handled.
Fixes#9469
Previously weren't registering modal properly, which gets fixed by
using open_modal. It further fixes closing of modal by using escape
and positioning of modal.
Fixes: #9590.
This directly prevents a traceback when submessage events
arrive in the wrong order. This was probably a symptom
of not updating message.submessages for not-yet-widgeted
messages, which was fixed in an earlier commit, but we
want defensive code in case of races or other glitches, and
it's not the end of the world is somebody sees partial
survey results due to some corner case.
The "if" condition that was removed in this commit
is no longer needed, since the called code now
handles the cannot-apply-locally use case. (We
wanted the called functions to be defensive, so
they already were effectively handling the conditions
anyway, and recent commits has them returning
appropriate values and doing the right things.)
This commit makes it so that any query for
which we do a local filter leads to us
examining the full list of unread message
ids in our cache to find a potentially
unread message that passes the filter. This
can often allow us to more immediately
jump to a new narrow with an appropriately
selected message.
Fixes#9319
We want to be able to call get_first_unread_info() even
if we cannot apply a search locally. It was returning
the correct value before, but this change removes a
blueslip warning that will allow our callers to remove
some guard code in a subsequent commit.
These styles aren't great, but they're hopefully
better than none at all and inspire a follow up
commit from somebody else (so it starts to look
like a "real" feature instead of feeling completely
proof-of-concept).
We want to update message.submessages for new events, even
though our couple of widgets (poll/tictactoe) that can process
"update" events currently just apply events as "deltas"
to their current data.
This does fix a subtle issue where you may get incoming
events for a message that the client knows about but which
it hasn't yet activated as a widget. Up until now,
we've rarely seen the bug that's fixed here, since it's
usually the case that as soon as we receive a message, we
widgetize it right away.
The user can now specify the value while creating a stream.
An admin can later change it via `Change stream permissions`
modal. Add is_announcement_only to subscription type text.
For some reason in my original version I was sending both
content and data to the client for submessage events,
where data === JSON.parse(content). There's no reason
to not just let the client parse it, since the client
already does it for data that comes on the original
message, and since we might eventually have non-JSON
payloads.
The server still continues to validate that the payload
is JSON, and the client will blueslip if the server
regressses and sends bad JSON for some reason.
Anupam Dagar
Tim Abbott
Steve Howell
Yashashvi Dave
Shubham Dhama
Eeshan Garg
Lyla Fischer
Max Nussenbaum
Akash Nimare
Shubham Padia