I like "sign in" better, but users from time
to time confuse "sign in" and "sign up" forms. To reduce
confusion potential, I'm renaming "sign in" to "log in".
* Log exception when email host not configured instead of raising assertion error
* Fix tests
* Reset to master
* Check email host before sending email for project invites
* Add "view on site" links in Check, Channel, and Project admins
* Expose over_limit_date in Profile admin
* Display last notify duration ("Time" column) in Channel admin
* Add last notify duration filter for Channel admin
* is_past_over_limit_grace(): Returns True if this profile is
over limits for 31 or more days.
* schedule_for_deletion(): Sets the deletion_scheduled_date
field to 31 days in the future.
If settings.EMAIL_MAIL_FROM_TMPL is set, it will be used
as the MAIL FROM (envelope sender) address.
The EMAIL_MAIL_FROM_TMPL value should contain a "%s" placeholder.
This is intended for routing email bounce notifications to a specific
MX server. For example, if the site runs on example.com
but we want to receive bounce notifications at the mail server running
on bounces.example.com, we can set
EMAIL_MAIL_FROM_TMPL = "%s@bounces.example.com"
Experimental, may change!
* Added duration to ping details. This is useful on a device with a small screen, since the duration cannot be seen in the main view so now one can see it in the ping's details.
* Changed terms across the board from "delta" to "duration"
* timedelta is now consistently imported as "td" across the entire project (even in Django generated migration files)
A similar issue has come up multiple times: the user
changes account's email address, enters a bad address
by mistake, and gets locked out of their account.
This commit adds an extra step in the "Change Email" flow:
* In "Account Settings", user clicks on [Change Email]
* User gets a prompt for a 6-digit confirmation code, which
has been sent to their old address. This is to prevent
account takeover when Eve sits down at a computer where Alice
is logged in.
* The user enters the confirmation code, and a "Change Email"
form loads.
* The user enters their new email address.
* (The new step!) Instead of changing the email right away,
we send a special login link to user's specified new address.
* (The new step, continued) The user clicks on the login link,
their account's email address gets updated, and they get
logged in.
The additional step makes sure the user can receive email
at their new address. If they cannot receive email there,
they cannot complete the "Change Email" procedure.
Accounts on self-hosted instances should have "unlimited" limits.
I had originally assumed 500 checks should be *enough for everybody*,
but in practice people do have accounts with 1000+ checks,
and may want to do scale testing with even more checks
(see #649). This commit raises the "unlimited" limits higher
to make it less likely users bump into them.
