My recent refactoring that split out MessageListData
introduced a nasty bug where we were putting muted
messages into the "All Messages" view even though
the underlying list was correctly filtering
them, so the symptoms were two-fold:
- muted messages cluttered up your feed
- replying to the message caused a traceback (since
it wasn't actually in the underlying data
structure)
This has to do with what MessageListData.add_messages()
was passing back to MessageList to orchestrate drawing
in MessageListView.
I think what happened here is I got this working kind
of sloppily but correctly for the non-muting case and
then got in the weeds of some other stuff. Not my
finest moment.
The actual correct code here is simple enough. We
triage top, interior, and bottom, and then the respective
methods that put the data into the data structure
return the filtered lists (i.e. not muted) and put them
into the info structure.
Fixes#9656
I guess we used to have a way to logout from within
settings, but the list item was always hidden when you
went into settings, so it's apparently just dead code,
and it's kind of a strange thing to have in settings.
We want to avoid doing too much setup for the info overlay widget
during initialization, since we don't really need it, and side
effects like focusing a modal can cause hard-to-detect
glitches for other features.
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 is preparation for an upcoming refactoring where we pass a bot
ID, not the email/api_key, into the zuliprc generation functions in
the bots code path.
We've for a long time had the behavior that a bot mentioned in a
stream message receives the notification, regardless of whether the
bot was actually subscribed to the stream.
Apparently, this behavior also triggered if you mentioned a bot in a
private message (i.e. the bot would be delievered the private message
and would probably respond unhelpfully in a new group private message
thread with the PMs original recipients plus the bot).
The fix for this bug is simple: To exclude this feature for private
messages.
What was happening before is that we built the webpack bundles in
tools/minify-js with nicely hashed filenames, and then `manage.py
collectstatic` was extending these filenames with a second hash
through the use of storage.
Removing the first one didn't seem ideal, but would probably have
worked, but seems confusing for people only familiar with webpack
(ideally, we want the Django toolchain piece to be increasingly
invisible as we replace it).
And we can't exclude the webpack bundles from being processed by
storage, since we need these bundles to be included in the manifest.
So, instead, we set the hash function to be a no-op for the bundle
files.
Fixes significant portions #5971.
More work is required to deal with versioning for some of the
image/font assets.
This should avoid us creating duplicate webpack bundles every time we
do a deployment, even if none of the files in the bundles themselves
have changed at all.
`format_as_suggestion` formats a list of operators into a
suggestion using the Filter.describe and Filter.unparse methods.
This change aims to increase readability.
The new can_access_all_realm_members function is meant to act as a
base function for guest users and Zephyr realm users regarding the
accessibility of the information of other users in the realm.
In admin UI for creating new choice type of custom field, the behavior
of trash icon for removing choice field is buggy.
When admin clicks on trash icon it disappears, but the row does not
and admin end up being unable to create the field.
Fix this by selecting proper element to find and delete choice row.
This fixes an issue where if you make #announce (the default
announcement stream) announce-only, then creating a new stream will
throw an exception (because notification-bot can't send there).
Fixes#9636.
These two slash commands now use zcommand to talk to
the server, so we have no Message overhead, and if you're
on a stream, you no longer spam people by accident.
The commands now also give reasonable messages
if you are already in the mode you ask for.
It should be noted that by moving these commands out of
widget.py, they are no longer behind the ALLOW_SUB_MESSAGES
setting guard.
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.