This fixes most of the current Travis CI failures, and should help
prevent future ones from cropping up, since we're just deleting Travis
CI's giant library of apt sources up front.
The production build is still failing, since apparently some of the
packages we were doing `apt-mark hold` on no longer exist.
This adds custom CSS through JavaScript for things that do not
scope well and will override other inherited styles.
This should ONLY be used for problematic CSS that has no obvious
or easy CSS-only solution.
(Specifically, we need this for the "default link" styling, which is
hard to override because we don't want to start winning ties due to
specificity that we would not have won in the light theme).
We'll need the expanded test coverage when we move
check_prereg_key_and_redirect to zerver/views/registration.py to avoid
test failures, and these are also tests we should really have anyway.
The previous code gave the user an extra day past
REALM_CREATION_LINK_VALIDITY_DAYS. Also rewrote it to match the parallel
logic in get_object_from_key.
Empirically, the retry in `_on_connection_closed` didn't actually work
-- if a reconnect failed, that was it, and the exception handler
didn't get run. A traceback would get logged, but all its frames were
in Tornado or Pika, not our own code; presumably something magic and
async was happening to the exception.
Moreover, though we would make one attempt to reconnect if we had a
connection that got closed, we didn't have any form of retry if the
original attempt at connecting failed in the first place.
Happily, upstream offers a perfectly reasonable bit of API that avoids
both of these problems: the on-open-error callback. So use that.
This method was new in Tornado 4.0. It saves us from having to get
the time ourselves and do the arithmetic -- which not only makes the
code a bit shorter, but also easier to get right. Tornado docs (see
http://www.tornadoweb.org/en/stable/ioloop.html) say we should have
been getting the time from `ioloop.time()` rather than hardcoding
`time.time()`, because the loop could e.g. be running on the
`time.monotonic()` clock.
Adding it afterward is inherently racy, and upstream's API is quite
reasonable for avoiding that -- just like we can pass an on-open
callback up front, we can do the same with the on-close callback.
This is a more thorough version of 4adf2d5c2 from back in 2013-04.
The default value of this parameter is already False upstream.
(It was already False in pika version 0.9.6, which we were
supposedly using when we introduced this in 4baeaaa52; not sure
what the story was there.)
This makes the gear-menu icon translucent rather than medium grey and
black (which isn't even our base text color) to be half opaque (approx)
and base text color.
This makes the compose icons translucent rather than medium grey
and black (which isn't even our base text color) to be half opaque
(approx) and base text color.
This changes it to be compatible with the dark-mode which involves one
change to light mode of changing a grey to a translucent white in
reactions.css.
There isn’t any reason for either of these mention code paths to be
using specified background types, so convert them all to background so
inheritance is more simple.
For setting the night mode, it checks to see if you’re in development
by checking `page_params.development`, but the actual attribute is
`page_params.development_environment`.
Previously, we weren't doing a proper left join in
user_groups_in_realm_serialized, resulting in empty user groups being
excluded from the query. We want to leave decisions about excluding
empty user groups to the UI layer, so we include these here.
This solves the issue with typeahead appearing in the middle of an
already-completed typeahead word.
Example: Earlier, '@ran|dom' would also trigger the typeahead and show
'random', but selecting it would turn it into '@**random** dom'.
We still have a problem to solve of preventing typeahead from
appearing on a space in the middle of an already-completed typeahead
word, but that is its own independent bug.
These are the exceptions to the rule that our queues correspond to
queue-processor workers.
Purging `notify_tornado` in particular is a useful workaround right
now for some error spew in the dev environment.
Because we use access_stream_by_id here, and that checks for an active
subscription to interact with a private stream, this didn't work.
The correct fix to add an option to active_stream_by_id to accept an
argument indicating whether we need an active subscription; for this
use case, we definitely do not.