Apparently this is a bug that slipped in when we started showing
normal users as deactivated in the user popovers: all bot users were
treated that way as well.
We'll want to do #7153 as a follow-up to get things fully working how
we want them.
While it's totally fine to put a leading '.' before the cookie domain
for normal hostnames and browsers will just strip them, if you're
using an IP address, it doesn't work, because .127.0.0.1 (for example)
is just invalid, and the cookie won't be set.
This fixes an issue where after installing with an IP address, realm
creation would end with being stuck at a blank page for
/accounts/login/subdomain/.
If an organization doesn't have the EmailAuthBackend (which allows
password auth) enabled, then our password reset form doesn't do
anything, so we should hide it in the UI.
We're going to end up deleting most of this in the next few commits;
the main goal here is to make it easy to code-review whether we're
breaking anything in replacing the built-in Django form's logic.
While our recent changing to hide /register means we don't need a nice
pretty error message here, eventually we'll want to clean up the error
message.
Fixes#7047.
This new function extractions the bit of logic we use after creating a
new user account to log them in and send them to the home page,
without emailing the user about their new login.
This should help prevent confusion where new users find themselves on
the LDAP login form and click "register" because they know they don't
have an account. Whereas in fact, their account will be auto-created
if they just login, so there's no need for them to access it.
This fixes a problem we've seen where LDAP users were not getting this
part of the onboarding process, and a similar problem for human users
created via the API.
Ideally, we would have put these fixes in process_new_human_user, but
that would cause import loop problems.
Now we use 'git ls-files' to get the list of locales that we actually
track. Previously we were using os.listdir to get the contents of the
static/locale directory. This could also return locales which were
present in the directory but are not supported by us, e.g. zh_CN.
Previously, if you had the streams overlay open (but no active stream
clicked) while another user edited your subscriptions state, we'd
throw an exception handle the get_events call, because the code for
rerendering the subscribers list didn't consider the possibility that
there was no active stream.
The recent fixes we made to make stream settings update properly when
doing live updates were great, but they would throw an exception if
the stream settings overlay wasn't open. This fixes that by adding
the appropriate check.
We do not want the code to lead to a path where it will attempt to
display native notifications if the “Notification” object doesn’t
exist, as this likely means that the device does not support OS
notifications.
Making the same point (that you can configure the notifications in
settings) at both steps felt pushy. I think the first prompt is
actually best kept to a minimum of words, so leave that one with
just the ask.
In the second step, try an active pitch. This could go either way, or
be any number of other messages, but the settings line felt a little
defensive to me, like it was suggesting that our notifications would
be noisy and here's a way you can try to mitigate that. I think with
our default settings (and in an org with mostly-reasonable humans, but
even a large and busy one) they're actually not at all noisy; and if
we learn of situations where that's not true, we'll work to fix that.
So, try this line instead.
A style note: I chose "your team" here to refer to the people the user
communicates with in their organization. We consistently say either
"organization" or sometimes "realm" for the concrete thing in the
product that is the whole universe of streams and users, etc., that a
given account lives in; but that feels too formal here. Conversely,
one reason we don't say "team" for an organization is that it feels
too cozy and small, more appropriate for 8 people who interact every
day than for 80 or 8000 people; but this line is mainly about those
8 people even if the organization has 8000. There are some examples
of this already in the codebase; see `git grep -w team`.
i18n note: These passages of a couple of connected sentences should
generally be marked for translation as one message, not several
separate ones. That helps the translator be sure of the context so
they can translate appropriately. For example, in the second prompt
in this version, there's an implicit "because" relationship between
the two sentences, and in some languages (I'm 90% sure this is true in
Japanese), it would be weird to leave it implicit and the second
sentence should contain the equivalent of "That's because".
This imposes a maximum width constraint on the center block so
that it can maintain readability and keep the content paragraphs
to less than 1000px.
Fixes: #7092.
This shows the text "Never" for users who are part of a realm but
have never been active, rather than a more vague JavaScript output
of "Invalid Date" due to the fact that their last presence
evaluates to NaN.
Historically, we'd just use the default Django version of this
function. However, since we did the big subdomains migration, it's
now the case that we have to pass in the subdomain to authenticate
(i.e. there's no longer a fallback to just looking up the user by
email).
This fixes a problem with user creation in an LDAP realm, because
previously, the user creation flow would just pass in the username and
password (after validating the subdomain).
This new test solves the problem that when we
made changes to the page-load codepath in the past,
it's been hard to identify what new code caused
more database queries. Now you can see query
counts broken out by event type.
This requires a small, harmless change to extract
an `always_want` function in `lib/events.py`.
Cynthia Lin
Tim Abbott
Steve Howell
Umair Khan
Alexis La Porte
rht
Brock Whittaker
darshanime
Greg Price
Eeshan Garg