E-mail issues

[orenyk]

Just testing some stuff out and came across the following:

1. The default e-mail contents still include some unescaped \ns that don't get processed by the mailer
2. The "Request Approved" e-mail doesn't send properly when the request starts today, instead it sends the "Checkout Reminder" e-mail
3. All of our default e-mail contents include a salutation (e.g. Dear @user@), but we've got one in the base template so it gets doubled. We should clarify this in our App Config instructions for the e-mail contents and adjust the defaults appropriately
4. In the UserMailer method it looks like there are two spaces in the subject between the equipment item name and the status (yay multiline strings), but that didn't appear in the actual e-mail so it's probably fine.

That's it for now, we should resolve these in v5.3.0 so that everyone's e-mails are good.

Edit 2015/05/06

We also have the reply-to / from for our admin e-mails set to no-reply@reservations.app... this seems a bit silly although at the same time the e-mail is coming from the application itself to the admin, so I don't know if there's a better option. At the very least since reservations.app will be a valid domain at some point in the near future, we should probably set this to something like no-reply@DOMAIN (e.g. no-reply@yale.edu) instead.

[esoterik]

converting the list to checkboxes for myself:

• The default e-mail contents still include some unescaped \ns that don't get processed by the mailer
• The "Request Approved" e-mail doesn't send properly when the request starts today, instead it sends the "Checkout Reminder" e-mail
• All of our default e-mail contents include a salutation (e.g. Dear @user@), but we've got one in the base template so it gets doubled.
  • We should clarify this in our App Config instructions for the e-mail contents and adjust the defaults appropriately
• In the UserMailer method it looks like there are two spaces in the subject between the equipment item name and the status (yay multiline strings), but that didn't appear in the actual e-mail so it's probably fine.
• We also have the reply-to / from for our admin e-mails set to no-reply@reservations.app... this seems a bit silly although at the same time the e-mail is coming from the application itself to the admin, so I don't know if there's a better option. At the very least since reservations.app will be a valid domain at some point in the near future, we should probably set this to something like no-reply@DOMAIN (e.g. no-reply@yale.edu) instead.