Hi Justin, On Sat, Jul 27, 2013 at 11:17 PM, Justin Michalicek <jmichali...@gmail.com>wrote:
> I would like to make my first contribution to the Django code, but these > both are pretty easy and at least to me seem pretty obvious, so I thought > there might be some good reason they have not yet already been done. > Depending on the response, I would do these in different ways as well, so I > want to check here before getting to work. > > 1) Adding an html_message parameter to django.core.mail.send_mail(), the > same as mail_admins() and mail_managers() have. Seems useful and like a > good idea, but it's dead simple, so it also seems like it would already be > there unless it for some reason had been decided that this is absolutely > not going to happen. > I believe the reason for this omission is mostly historical. Once upon a time, we were trying to avoid building specialist mail APIs, preferring to encourage people to use Python's native mail facilities. Extensions that added features to Django's mail APIs were shunned in favour of relying on native Python functionality. However, at some point, simple practicality takes over. Given that mail_admins() and mail_managers() both accept html_message as an argument, I can't see any good reason why send_mail shouldn't accept the same. > 2) Adding the ability for django.contrib.auth.views.password_reset() to > take an optional parameter for an html email template as well as > django.contrib.auth.forms. > > PasswordResetForm.save() so that html password reset emails may be sent. > Again, simple enough that I worry that there's a reason this isn't already > done that I'm unaware of. > It is also somewhat dependent on #1 there in that either #1 has to be done > first or this has to be done by using EmailMultiAlternatives directly rather > than send_mail(). > > Again, this likely a historical oversight. I can't see any reason that we shouldn't provide HTML mail as an option here. The only caveat I would place on both these feature requests is that you need to be careful about backwards compatibility -- existing functionality should not change as a result of adding these new features. However, this should be fairly easy to manage - you just need to make sure that you provide default arguments that are ignored, and that output for the current supported cases isn't altered. > Any input on if I should proceed or if there's some reason I should not touch > these would be greatly appreciated. I'd love to make a contribution to > Django and these look > like a safe, simple, and useful place to start. > > > Indeed -- you've picked two relatively simple extensions to existing APIs. Make sure you've read Django's contribution guidelines [1], open a ticket on Trac [2], and submit a patch or pull request. Can't wait to see what you can contribute! Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
