Opened 13 years ago
Closed 11 years ago
#17431 closed New feature (fixed)
Allow PasswordResetForm subclasses full control over email message to send
Reported by: | Ethan Jucovy | Owned by: | jorgecarleitao |
---|---|---|---|
Component: | contrib.auth | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | timograham@…, jorgecarleitao | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | yes |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
The django.contrib.auth.forms.PasswordResetForm
has logic to:
- Validate that an active user exists with the email address provided
- Generate an unguessable URL for the given user to reset his password using a timestamped token
- Construct an email with a link to that URL
- Send that email to the given user's email address
The .save()
method of the form class is responsible for three of these four tasks. The .save()
method includes parameters for overriding the subject, body, and From:
address of the email to be sent. However, it's sometimes necessary to have more control over the email that will be sent. These use cases could include:
- BCC'ing a site administrator with a copy of the email sent
- Setting a custom
Reply-To
like "password-reset-help@…" that is distinct from the message'sFrom:
address - Setting a
text/html
MIME type for the message, or using anEmailMultiAlternatives
object to attach both text and HTML versions of the message
For all of these use cases, the knobs currently provided are insufficient, and require copying over all the logic in the .save()
method.
The attached patch satisfies these use cases by allowing the user to subclass PasswordResetForm and override a .construct_email()
method, whose job is to construct and return an EmailMessage
to be sent by the .save()
method. The changes are fully backwards-compatible, and a test demonstrating the subclassing approach is provided.
Attachments (1)
Change History (10)
by , 13 years ago
Attachment: | password_reset_custom_email.diff added |
---|
comment:1 by , 13 years ago
Triage Stage: | Unreviewed → Accepted |
---|
follow-up: 3 comment:2 by , 13 years ago
comment:3 by , 13 years ago
Replying to anonymous:
My need is to include an additional variable in the context that is used to render the email template. I don't see that the patch provided supports that use case?
Where will your extra context variable be coming from?
If it's something that you can derive without access to a request, then you can just inject it into the context in your overridden construct_email
method. Likewise if it's something derived from request.POST
then self.data
will contain the full POSTed form, and you can inject your needed variable in construct_email
.
comment:5 by , 12 years ago
Thanks ejucovy
+1 on this;
we definitely need to have full control on the sent email template and context.
comment:6 by , 11 years ago
Cc: | added |
---|---|
Patch needs improvement: | set |
Patch needs to be updated to apply cleanly.
comment:7 by , 11 years ago
Cc: | added |
---|---|
Owner: | changed from | to
Status: | new → assigned |
Pull request https://github.com/django/django/pull/2642
comment:8 by , 11 years ago
Needs documentation: | set |
---|---|
Patch needs improvement: | unset |
The patch is promising. It still needs more docs however (release notes and also the construct_email
method documentation).
comment:9 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
My need is to include an additional variable in the context that is used to render the email template. I don't see that the patch provided supports that use case?