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.
The top and bottom sections of the lightbox overlay do not close the
lightbox when clicked. Now, this triggers the close_overlay path when a
valid non-actionable background element is clicked.
Fixes: #7500.
Using user_group_name_dict.get() will return `undefined`.
`blueslip.error` statement caused an exception notification to the
admins.
Tweaked by tabbott to add a test for a nonexistent group.
tools/setup/generate_zulip_bots_static_files now starts off by
deleting static/generated/bots/ (if it hasn't been removed already)
so that outdated static files from older versions of the zulip_bots
package don't supress errors in the main repo that would otherwise
break.
For more info, see #7542Fixes: #7542.
For example, this means that if a user already has an account on one
realm and they try to make an account on another by hitting "Sign in
with Google" (rather than following the little "Register" link to a
"Sign up with Google" button instead), they'll get to make an account
instead of getting an error.
Until very recently, if the user existed on another realm, any attempt
to register with that email address had to fail in the end, so this
logic gave the user a useful error message early. We introduced it in
c23aaa178 "GitHub: Show error on login page for wrong subdomain"
back in 2016-10 for that purpose. No longer! We now support reusing
an email on multiple realms, so we let the user proceed instead.
This function's interface is kind of confusing, but I believe when its
callers use it properly, `invalid_subdomain` should only ever be true
when `user_profile` is None -- in which case the revised
`invalid_subdomain` condition in this commit can never actually fire,
and the `invalid_subdomain` parameter no longer has any effect. (At
least some unit tests call this function improperly in that respect.)
I've kept this commit to a minimal change, but it would be a good
followup to go through the call sites, verify that, eliminate the use
of `invalid_subdomain`, then remove it from the function entirely.