In our toggler component (the thing that handles tabs in things
like our markdown/search help, settings/org, etc.), we have
a callback mechanism when you switch to the tab. We were
being tricky and only calling it when the tab changed.
It turns out it's better to just always call the callback,
since these things are often in modals that open and close,
and if you open a modal for the second time, you want to do
the callback task for whichever setting you're going to.
There was actually kind of a nasty bug with this, where the
keyboard handling in the keyboard-help modal worked fine the
first time you opened it, but then it didn't work the second
time (if you focused some other element in the interim), and
it was due to not re-setting the focus to the inner modal
because we weren't calling the callback.
Of course, there are pitfalls in calling the same callbacks
twice, but our callbacks should generally be idempotent
for other reasons.
We want the Botserver to not only work with the
botserverrc, but also with a zuliprc of an outgoing
webhook. Because the Botserver uses the outgoing
webhook token for authentication, we need to include
it in the zuliprc for outgoing webhooks.
This adds a /ping command that will be useful for users
to see what the round trip to the Zulip server is (including
only a tiny bit of actual server time to basically give a
200).
It also introduce the "/zcommand" endpoint and zcommand.js
module.
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.
This is preparation for our migration of our JS pipeline to webpack,
which includes as part of the process a hack of exporting globals via
the window object.
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.
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.
Fixes#3380.
The blueslip warning mentioned in #3380 were from paths ending at
people.email_list_to_user_ids_string. Some additional blueslip warnings
were raised after using that function.
Although we can put a validation check somewhere in the call stack of
people.email_list_to_user_ids_string, this function itself is used to
validate the operand by the higher order functions, so it wouldn't make
sense to put a validation check before that. Instead, removing the
blueslip warning altogether was chosen.
people.email_list_to_user_ids_string was replaced by
people.reply_to_to_user_ids_string which is a blueslip-free version
of the same. Other blueslip warnings were removed.
If atleast one of the private_message_recipients is invalid, compose
box will not be opened.
Thanks to Aastha Gupta <aastha.gupta4104@gmail.com> for some preliminary
work on this.
The Botserver uses section headers in the flaskbotrc to
determine which bot to run. Silently setting the section
headers to a bot's username is confusing and makes it
harder for Botserver users to figure out how to get the
Botserver to run the bots they want. This commit empties
all flaskbotrc section headers and thus makes the assignment
of bots explicit and mandatory.
Fixes#6515.
New suggestions for `sender:King ha` will respect spaces and the new
suggestion will be `Sent by King Hamlet <email>` instead of `Sent by King,
search for ha`. But if first term of sender operand is a valid user email,
tokens will be seperated by spaces. e.g `sender:hamlet@zulip.com abc`
will show `Sent by King Hamlet <email>, search for abc`.
This starts the concept of a schema checker, similar to
zerver/lib/validator.py on the server. We can use this
to validate incoming data. Our server should filter most
of our incoming data, but it's useful to have client-side
checking to defend against things like upgrade
regressions (i.e. what if we change the name of the field
on the server side without updating all client uses).
We have less urgency to test all templates now. The
most common error is probably unbalanced tags, and our
python-based template checker catches those problems
pretty well.
It's still possible to create bad templates, of course,
but the node tests have never been super deep at finding
semantic errors.
This is a trial to have the first reply hotspot in the bottom
whitespace (and stick there until "Got it!" is pressed).
Tweaked by tabbott to clean it up a bit. Still needs more work on the
visuals.
Steve Howell
Robert Hönig
Anupam Dagar
Joshua Pan
Tim Abbott
Shubham Padia
Shubham Dhama
Yashashvi Dave
Cynthia Lin