Add default email template #1898
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,5 @@ | ||
| <html> | ||
|
There was a problem hiding this comment. I think this is redundant -- we tell users to include their own There was a problem hiding this comment. Also, this file should either be called |
||
| {% autoescape off %} | ||
| {{ msgbdy }} | ||
|
There was a problem hiding this comment. If |
||
| {% endautoescape %} | ||
|
There was a problem hiding this comment. I wonder if the default template should include an unsubscribe footer that links to the disable account page. (If so, the text should definitely say so.) There was a problem hiding this comment. 👍 👍 👍 and maybe some phone-compatibility code? If we include unsubscribe footers (I have a good one of those that I can add) and other stuff, then does that tie us into making them use HTML or Markdown? There was a problem hiding this comment. If we're allowing both HTML and plain text, we probably actually want to have two templates; the plain-text one can just include the URL. What do you mean by phone-compatibility code? There was a problem hiding this comment. Also, if we want, we could consider including a per-user unsubscribe link that doesn't require logging in, since making people log in to unsubscribe is really annoying. It would require a bit more code so perhaps it's better to do that separately. There was a problem hiding this comment. I mean code that makes emails display more nicely on phones (there are sometimes issues with rotating screens and font sizing that you can throw enough HTML at to make them vanish). The per-user link would be nice if that's possible. We can also include an "email us if you want to unsubscribe" if the additional code wouldn't be worth the hassle. There was a problem hiding this comment. Huh, ok, cool. If by "email us if you want to unsubscribe" you intend for a human to handle it, that's fine; we can't really do an automated thing since the from/reply-to could be an arbitrary address controlled by the chapter. There was a problem hiding this comment. Yes, sorry. I mean for humans to handle the request if logging in is annoying or they forgot their password. There was a problem hiding this comment. If we have a nice template, making a 1-click unsubscribe wouldn't be too hard -- there might even be a library that will do most of the work for us. But in any case, we can do that after this is merged. |
||
| </html> | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -38,7 +38,8 @@ <h2>Step 2:</h2> | |
| Please write your email/message now. Note that you can use <tt>{{ parameter }}</tt> to enter a parameter | ||
| into the text of the message—the parameters are listed below. | ||
|
|
||
| <p><b>Tip:</b> The default {{ settings.ORGANIZATION_SHORT_NAME }} template (which you can modify <a href="/admin/utils/templateoverride/">here</a>) is automatically wrapped around your message below. | ||
|
There was a problem hiding this comment. You can actually probably link straight to There was a problem hiding this comment. That's a great idea! Thanks! I forgot you could search by name. I'll add that in once we settle on a good name for file, which will probably depend on what we decide for this guy. |
||
| Don't forget to write the body in HTML, but no need for <html> and </html> tags.</p> | ||
|
There was a problem hiding this comment. We should still allow writing plain-text emails, because it's easier and if you don't need any formatting it's better. (Ideally we may want to switch to Markdown for emails, because that's both easier and can be used to make pretty things.) There was a problem hiding this comment. Yeah, my thought was to include a default HTML email that did something basic (such as replacing newlines with paragraph tags, adding some kind of standard unsubscribe message, and maybe some phone-compatibility things) but benign so that it will automatically format it a bit for them. Most of the chapter board was very enthusiastic about this idea, and it seems nice to include some baseline level of professionalism (it's actually illegal to send mass emails like ours without some unsubscribe instructions, for instance, and unformatted plain text doesn't look very nice). Of course, programs could modify this file as they wish (that's the whole point), but having a default with some easy prettify-ing HTML in there seems like a nice way to add a little style to the emails. But of course I'm open to discussion on this point There was a problem hiding this comment. If we want to do that, we should actually do that, probably by converting markdown (perhaps optionally). You can look at how we do it for QSD as a guide. If we do that I'm fine not allowing plaintext, but as I understand it, as-is this will just eat the newlines and such, and I do think for short emails unformatted text looks fine. Incidentally, I believe CAN-SPAM doesn't actually apply to our use case since we are non-commercial and all users have signed up for our mailing list by registering an account, although we certainly should include unsubscribe links. There was a problem hiding this comment. Also, while we're considering this, we may want to think about whether we should always be attaching a plain-text version of HTML emails, since there are still some email clients that will be sad if you don't. If we do markdown and people don't include raw HTML tags, this is fairly easy; in the more general case it could be a lot trickier. So we may not want to bother, or if we do, may want to do it in a separate pull request. There was a problem hiding this comment. I think it would be nice to do the full-blown version. I'll take a look at the markdown conversion. Good call on including the plain-text version though. That seems worth doing. And maybe a line to the effect of "click here to see this email in your browser" if we can manage that without too much trouble? I'm kind of tempted to force admins to write in something that looks nice. We could include an optional if-statement to catch emails under 50 words with no formatting tags (or whatever) that would just wrap them in <p> tags and add the default headers/footers and for emails over 50 words, require admins to use HTML. Thoughts on that? There was a problem hiding this comment. "Click here to see this email in your browser" is fairly reasonable; we'd just have to render the same template into a page. The only problem is that we'd either have to always make people log in for it, or somehow make it user-specific without doing that, which is a little tricky to do correctly (i.e. without leaking user data). But it's probably doable. Markdown seems better (and probably easier) than trying to autowrap Incidentally, we'll want to make sure the release notes of whatever release this goes in include a mention of the fact that the defaults have changed, since some of these are breaking changes. There was a problem hiding this comment. Okay, cool. I don't know how to safely render emails without making them log in, but I can search around a bit. Sounds good. I'm not super familiar with how Markdown works, but I'll check out the QSD-conversion code and see if I can figure out how to adapt it. Good call on the release notes. At this point, I think I should open a new pull request after making some changes to this one. To summarize, next steps are:
There was a problem hiding this comment. Basically we'd want to do it similar to an unsubscribe link: give each user a unique unguessable link, which the website can decode to get their username and therefore render the correct email for them. I'm not sure what the best way to do that in practice is, but there may be some package out there that will do the crypto for you. For release notes, if you want you can just add a blank release notes file now, and put your stuff in it, or you can do it when we actually get around to cutting the release. It would probably be nice if we did more of the former, but since we haven't in the past it's fine if you want to do the latter. Those steps sound good! |
||
|
|
||
| <form action="/manage/{{program.getUrlBase}}/commprev" method="post" name="comm2"> | ||
| <table border="0" cellspacing="0" width="100%"> | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the more standard thing is to use
render_to_string()rather thanget_template()andunicode(), and in that case you don't need to call theContextinstance yourself, you just pass a dict.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I think you want
htmlbodyinstead ofbodyhere, otherwise lines 105-108 are meaningless. Also also, passing the user and program in here is unnecessary.Edit: Oh, I see why you might want to. I guess it's fine, although it might be good to have a warning somewhere (not sure where) that if you modify the template you should make sure not to use any user vars (ideally not even any program vars) inside the
{% autoescape off %}block.