Generated by `pyupgrade --py3-plus --keep-percent-format` on all our
Python code except `zthumbor` and `zulip-ec2-configure-interfaces`,
followed by manual indentation fixes.
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
Apparently, we didn't have any database indexes on Confirmation, which
meant that on servers with large numbers of users like zulipchat.com,
new account registration could spend a ton of time effectively doing a
table scan on this table.
The value of realm attribute in confirmation object used to be empty
before. We are not currently using the realm attribute of reactivation
links anywhere. The value of realm stored in content_object is currently
used.
This adds a web flow and management command for reactivating a Zulip
organization, with confirmation from one of the organization
administrators.
Further work is needed to make the emails nicer (ideally, we'd send
one email with all the admins on the `To` line, but the `send_email`
library doesn't support that).
Fixes#10783.
With significant tweaks to the email text by tabbott.
Now, there's just one spot at the beginning of the function where we
inspect the string key the user gave us; and after that point, we not
only have validated that string but in fact are working from our own
record that it pointed to, not the string itself.
This simplifies the code a bit, e.g. by not repeatedly searching the
database for the key (and hoping everything agrees so that we keep
getting the same row), and it will simplify adding logic to inspect
row attributes like `presume_email_valid`.
The previous code gave the user an extra day past
REALM_CREATION_LINK_VALIDITY_DAYS. Also rewrote it to match the parallel
logic in get_object_from_key.
This change:
* Prevents weird potential attacks like taking a valid confirmation link
(say an unsubscribe link), and putting it into the URL of a multiuse
invite link. I don't know of any such attacks one could do right now, but
reasoning about it is complicated.
* Makes the code easier to read, and in the case of confirmation/views.py,
exposes something that needed refactoring anyway (USER_REGISTRATION and
INVITATION should have different endpoints, and both of those endpoints
should be in zerver/views/registration, not this file).
Except in:
- docs/writing-bots-guide.md, because bots are supposed to be Python 2
compatible
- puppet/zulip_ops/files/zulip-ec2-configure-interfaces, because this
script is still on python2.7
- tools/lint
- tools/linter_lib
- tools/lister.py
For the latter two, because they might be yanked away to a separate repo
for general use with other FLOSS projects.
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)
Anders Kaseorg
Tim Abbott
Vishnu KS
Anders Kaseorg
Raymond Akornor
Aditya Bansal
Greg Price
rht
Rishi Gupta
sandeepsajan0
Vishnu Ks
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