Also adds Confirmation.type, and cleans up the rest of Confirmation to look
more like the model definitions in zerver.
In the migration, all existing confirmations adopt the type
USER_REGISTRATION, to be conservative. In a few commits, different
confirmation types will have different validity periods, and
USER_REGISTRATION will have the shortest default.
This commit removes the ability to configure different validity durations
for different types of confirmation links. I don't think the extra
configurability was worth the extra complexity, either for the user trying
to understand the settings, or for the developer trying to understand the
code.
The commit replaces all confirmation validity duration settings with a
single setting, settings.EMAIL_CONFIRMATION_DAYS.
The only setting it removes is settings.EMAIL_CHANGE_CONFIRMATION_DAYS,
which was introduced in 5bf83f9 and never advertised in prod_settings.py.
Wasn't being used outside the file, the URL is specific to
ConfirmationManager, and it makes
EmailChangeConfirmationManager.get_activation_url more obviously parallel
to ConfirmationManager.get_activation_url.
I think it makes sense to wrest the email sending from confirmation, now
that we have a clean email-sending interface in send_email. A few other
reasons:
* send_confirmation is get_link_for_object followed by send_email, but those
two functions have no arguments in common.
* Sending email through confirmation obfuscates the context dict, and is a
relatively complicated piece of the codebase anyone trying to deal with
the email system has to understand.
* The three emails previously being sent through confirmation don't have
that much in common, other than that they happen to have a confirmation
link in them.
The .split('/')[-1] in registration.py is a hack, but a hack used several
places in the codebase, so maybe one day get_link_for_object will also
return the confirmation_key.
This commit replaces all uses of django.core.mail.send_mail with send_email,
other than in the password reset flow, since that code looks like it is just
a patch to Django's password reset code.
The send_email function is in a new file, since putting it in
zerver.lib.notifications would create an import loop with confirmation.models.
send_future_email will soon be moved into email.py as well.
No change in behavior; render_to_string(template, context) is a shortcut for
get_template(template).render(context). render_to_string is the function we
use to render email templates in the rest of the codebase.
I think it's fine to trust that we won't mess this up. I assume this is here
because it was copied from similar code in Django (e.g. see our code from
the password_reset flow), rather than because it was a problem in our
subject templates.
Relies on the fact that all the email template names now follow the same
pattern.
Note that there was some template_prefix-like computation being done in
send_confirmation (conditioned on obj.realm.is_zephyr_mirror_realm); that
computation is now being done in the callers.
These make sense to be tagged for translation if one is using the
Django admin UI, which we're not. As it was, they just wasted a bit
of time for our translators.
Change `from django.utils.timezone import now` to
`from django.utils import timezone`.
This is both because now() is ambiguous (could be datetime.datetime.now),
and more importantly to make it easier to write a lint rule against
datetime.datetime.now().
This adds to Zulip support for a user changing their own email
address.
It's backed by a huge amount of work by Steve Howell on making email
changes actually work from a UI perspective.
Fixes#734.
This makes life a lot easier for people inviting users to a new Zulip
organization, since they can give some form of context now.
Modified by tabbott to clean up CSS, backend code flow, and improve
the formatting of the emails.
Fixes: #1409.
This commit adds html versions of the invite and signup mails and renames
the existing .txt files to the preferred file extensions '.subject', '.html'
and '.txt'. The html versions of the mails are being sent along with the
text-only versions by the 'send_confirmation' function.
This fixes#3134.
Adds a function which returns the number of days for which
a confirmation link will remain valid. This function can be
overridden by derived classes to provide a different value.
The MitUser model caused a constant series of little problems for
users with mit.edu email addresses trying to sign up for different
Zulip servers.
The new implementation just uses conditionals on the realm object when
selecting the confirmation template to use.
Activation emails were using django's sites framework which always has
the domain set to zulip.com.
(imported from commit b81eae96e1a75b64dd93970760b869f3271ce88c)
django.utils.timezone.now returns an aware datetime object because USE_TZ =
True.
Fixes#80.
(imported from commit c60f491fe00a98626ecced94fc3ea1f71f939a38)
I am pretty sure there's no point to using a hash at all. But until I hear
back from the author, let's at least make sure we put as much entropy into the
hash as we expect to get out of it.
(imported from commit 51a231adeab014cc1af8cb67e89baf06e0a1f593)
Rishi Gupta
hackerkid
Tim Abbott
Raghav Jajodia
Umair Khan
Ayush Jain
Robert Hönig
Rohith Asrk
nikolay
Rishi Gupta
Tim Abbott
Reid Barton
David Roe
Jason Michalski
Jessica McKellar
Luke Faraone
Keegan McAllister