From the docs:
> This function does nothing if the root logger already has handlers
> configured for it.
Which we do if we've started up Django and configured settings, and in
particular allowed Django to process `settings.LOGGING`.
So, cut it out -- all it can do is confuse people about how logging
works.
If we ever actually used the `log_format` parameter, this would be
doubly confused, because only the first call would have any effect.
Because calls to `create_logger` generally run after settings are
configured, these would override what we have in `settings.LOGGING` --
which in particular defeated any attempt to set log levels in
`test_settings.py`. Move all of these settings to the same place in
`settings.py`, so they can be overridden in a uniform way.
This is already the loglevel we set on the root logger, so this has no
effect -- except in tests, where `test_settings.py` attempts to set
some of these same loggers to higher loglevels. Because the
`create_logger` call generally runs after we've configured settings,
it clobbers that effect.
The code in `test_settings.py` that tries to suppress logs only works
because it also sets `propagate=False`, which has nothing to do with
loglevels but does cause logs at this logger (and descendants) to be
dropped completely unless we've configured handlers for this logger
(or one of its relevant descendants.)
Adds a markdown preprocessor that finds ordered lists where all items
use the same number and change them to be in normal increasing order,
starting with that number.
Fixes#5159.
I've wanted this when looking at a tab from the day before.
Also provides the date and time in UTC, which is handy for
interpreting some of the data.
Pretty sure this is not the world's cleanest way to do this in the
front-end code. It'll do for now.
Not only does this look better, but in the parallel case of ≤
(coming soon) it prevents a naive parser, like in our linter,
from getting confused by seeing a "<" character.
These aren't of much use without the corresponding secrets (despite us
calling one of them a "key", both are public IDs), which are in my
personal dev-secrets.conf. So, remove them.
I had this commit applied in order to test what became 90944983f...
and then I accidentally included it in what I pushed, as 0fa9a489d.
Oops.
When a user with no account tries to login using GitHub/Google auth
they are given an option to register. If the user chooses to
register, a mail is sent for verification and the user has to continue
registration as if they signed up using email. This is confusing and
a bit annoying, so instead of sending email I have changed the
procedure to just redirect to /register where they can start
registration over and proceed normally.
An ideal implementation for this would be to just allow users to
continue registration without email or going back to register.
[greg: tweaked to keep existing user-facing text]
Eventually this check for the realm will be done in get_object_from_key
itself. Rewriting this to fit the pattern in get_object_from_key.
No change to behavior.
Commit d4ee3023 and its parent have the history behind this code.
Since d4ee3023^, all new PreregistrationUser objects, except those for
realm creation, have a non-None `realm`. Since d4ee3023, any legacy
PreregistrationUsers, with a `realm` of None despite not being for
realm creation, are treated as expired. Now, we ignore them
completely, and remove any that exist from the database.
The user-visible effect is to change the error message for
registration (or invitation) links created before d4ee3023^ to be
"link does not exist", rather than "link expired".
This change will at most affect users upgrading straight from 1.7 or
earlier to 1.8 (rather than from 1.7.1), but I think that's not much
of a concern (such installations are probably long-running
installations, without many live registration or invitation links).
[greg: tweaked commit message]
This reverts commit eb2bdb706 "sidebar: Narrow to latest topic if
not in stream." On a trial deploy, many users were surprised and
preferred the old behavior.
This reverts commit aebf63c28 "sidebars: Change to more muted
hover/active colors."
In addition to the effects described in its commit message, this
commit gave the unread counts in the left sidebar a much lighter
background, making them harder to see. I'm not quite sure which part
of this change caused that effect how; reverting for now and we
can sort out a new version of the change.
Greg Price
Weronika Grzybowska
Nikhil Kumar Mishra
Steve Howell
Rhea Parekh
ryan
Utkarsh Patil
Cynthia Lin
kunall17
Rishi Gupta
Xavier Cooney
picapi_
Vishnu Ks
Shreyansh Dwivedi
Brock Whittaker