We essentially stop running create_realm_internal_bots during
every provisioing and move its operations to run from populate db.
In fact to speed things up a bit we actually make populate db call the
funcs which create_realm_internal_bots calls behind the scenes.
Fixes: #9467.
We extract the entire operations of the management command to a
function create_if_missing_realm_internal_bots in the
zerver/lib/onboarding.py. The logic for determining if there are any realm
internal bots which have not been created is extracted to a function
missing_any_realm_internal_bots in actions.py.
This is required because the --settings=zproject.test_settings param
doesn't work with migrate or the dumpdata management commands. Thus
untill now if one ran just this tool ended up with test database not
properly setup. We never noticed this because test-backend ran this
tool again (after exporting DJANGO_SETTINGS_MODULE) thus making the
tool work this time.
I've often done this by hand -- basically typed out the last line,
with the variables found from looking at the PR page in a browser.
Seems nicer for both us maintainers and the contributor, in particular
because the PR gets marked as merged, instead of closed. But it's a
bit of a pain, and I do it maybe half the time or less; plus it's kind
of a subtle GitHub feature, and as a result I think other maintainers
of Zulip repos do this approximately never.
I've always figured this couldn't be hard to automate; today I decided
to take the 45 minutes to look up how, write out the script, QA it,
write up a nice usage message and some comments, and commit it. :)
We can have this scenario:
- somebody else creates a widget-ready message
- message arrives in storage
- (message is not yet in view, so no message.widget)
- new submessage event arrives
We want to just ignore submessage events in that case.
(There's a more complete fix coming for this scenario, where
we at least update message.submessages for the eventuality
that we do render the message later.)
This isn't a complete long-term fix, in that ideally we'd be doing
this check at the view layer, but various structural things make that
annoying, and we'll want this test either way.
This commit improves the output that blueslip produces while
showing error stack traces on the front-end. This is done by
using a library called error-stack-parser to format the stack
traces.
This commit also edits the webpack config to use a different
devtool setting since the previous one did not support sourcemaps
within stack traces. It also removes a plugin that was obviated
by this change.
Previously, the stream colors index i was accidentally a function only
of the user, so each user got the same color for all their streams.
This should provide a lot nicer-looking development environment
experience.
Apparently, our nginx configuration's use of "localhost", combined
with the default in modern Linux of having localhost resolve to both
the IPv4 and IPv6 addresses on a given machine, resulted in `nginx`
load-balancing requests to a given Zulip server between the IPv4 and
IPv6 addresses. This, in turn, resulted in irrelevant 502 errors
problems every few minutes on the /events endpoints for some clients.
Disabling IPv6 on the server resolved the problem, as does simply
spelling localhost as 127.0.0.1 for the `nginx` upstreams that we
declare for proxying to non-Django services on localhost.
This improves test coverage for a lot of our webhooks that relied
on ad-hoc methods to handle unexpected event types.
Note that I have deliberately skipped github_legacy, it isn't
advertised and is officially deprecated.
Also, I have refrained from making further changes to Trello, I
believe further improvements to test coverage should be covered
in separate per-webhook commits/PRs.
UnexpectedWebhookEventType is a generic exception that we may
now raise when we encounter a webhook event that is new or one
that we simply aren't aware of.
Fixes#9492.
`is` operator uses predefined categories. This commit
displays an invalid operand message if the operand does not fall into
any of these categories and the `is` operator is not at the last.
e.g. `is:abc sender:abc@zulipchat.com` will have `invalid abc operand
for has operator, sent by abc@zulipchat.com` as a prefix for all its
suggestions.
Fixes#9492.
Default suggestion e.g `abc messages` as a suggestion for `is:abc`
is not shown in a new suggestion. But if the is operator is already
present before any other operator, the default message text will be
used. e.g `is:abc sender:abc@zulipchat.com` will have all the suggestions
with the prefix `abc messages, sent by abc@zulipchat.com`.
The mypy daemon only supports error and skip. Choosing error
immediately surfaces when a file excluded from the build is
being imported, so that something can be done about it.
`get_containing_suggestions` was used to get the operand suggestions
for the `has` operator. `get_special_filter_suggestions` is now used
to get both the operand and operator suggestions for `has`.
Partially fixes#9461.
Negated suggestion for both operand and operators are handle in
get_special_filter_suggestions. A bug is get_operator_suggestions
causing the removal of `-` symbol from the operand was also fixed.
Now that we've moved it into a bulleted set of options inside a modal,
there's no good reason to have separate variables for the corner cases
around who can manage a stream.
Commit fa18913b8 preserved the fix to the actual import, but added
back the `ignore_missing_imports` line that had shielded the
erroneous import. Remove that line again.
Our logic for stream_has_topics never accounted for
us creating essentially "empty" stream buckets that
don't have topics, but we recently added some code
related to unread counts that violated the original
assumptions of the code.
Now we check deeper into the stream bucket to find
actual topics.
This bug manifested in the left sidebar where users
were seeing streams as recently active just because
some muted topics had unread counts, when in fact
the stream was inactive for practical purposes.
Having submessages will become common enough that the
info message here is too spammy, and there are other
ways to observe incoming submessages if you're doing dev
debugging, which this was originally written for.
We could get submessage events for messages that weren't
in our message store if somebody played with a widget
that was on an "old" message for somebody else.
We've had this sort of logic for GCM for a long time; it's worth
adding for APNS as well.
Writing this is a bit of a reminder that I'm not a fan of how our unit
tests for push notifications work.
Dropdown element for outgoing interface type was not showing correct
value, cause the way default value was set to dropdown was incorrect
(it should have been setting the selected parameter on the selected
option if it were going to be selected via the template code).
Fixes#9419.
Robert Hönig
Aditya Bansal
Sampriti Panda
Shubham Dhama
Greg Price
Steve Howell
Tim Abbott
Armaan Ahluwalia
Eeshan Garg
Umair Khan
Shubham Padia
Michael J. Sullivan
Yashashvi Dave