Basic Email Templating, Confirmation Logic & Mobile Styling Fixes

[JackRichard889]

Can close #84, #99, and #117.

I made a text and HTML version of the "email templates," which is really just one mediocre template right now. Django recommends an alternate version of the email for weird browsers and email clients.

Some of the parts of the app looked really strange on mobile, so I tried to fix it as much as possible on smaller screen sizes.

The confirmation logic includes a URL to confirm a reservation and two Django template filters to calculate confirmed reservations from a set. Also fixed all of the "available" and "taken" counts that had to be changed.

[seamussmith]

I probably should have been a bit more clear about where to put the email templates.

When I said I wanted the email templates in the /email/layouts/ directory, I was referring to the template import path name, the path you use to reference to the template. I probably should have made this more clear, and I plan to update the documentation on our template directory schema.

I'll give you a rundown on how we store our templates:

Django looks at the templates folder of each app in a project and allows developers to refer to them without using a relative directory, like for instance, the template with the path /app/templates/app/pages/index.html can be referred to as /app/pages/index.html. The reason why the front-end templates are in an extra /app/ folder is to create a separation of concerns. If we have all of our templates in the base template folder, we would run into name collisions and it would be, in general, very messy.

When we need templates for other things, like emails, we would have another folder called email in our /app/templates/ folder. The folder structure could probably follow in the footsteps of our app templates, with the whole components layouts pages schema. pages in this case could be renamed to something more sensible like emails.

Our templates usually also extend from a base template to reduce code duplication on things like headers and footers. In the case of emails, our base template would most likely have a header and a signature at the end. This template would sensibly go in the /emails/layouts/base.html template directory.

I hope this clears any confusion.

[seamussmith]

You should probably use the new model URL converters. We have them for Schedule, TimeSlot, and Reservation. These URL converters allow us to eliminate that one line of code used for fetching the data from the database. You can look at how these converters are implemented in the app.converters module.

In this case here, you would change the <int:reservation> to <reservation:reservation> to take advantage of the URL converter.

[ghost]

Not necessarily. Project level templates can be used for system level templates. Account creation, and Password reset emails for example fall into this category. But I can see that these email templates are coupled with the functionality of “app” so it makes sense to put these there in hindsight. I just wanted to clarify this. Also, it may not be useful to extend base in email templates. Instead you may want to create an email base instead. -Mr. L

On Thu, Mar 17, 2022 at 4:34 PM Seamus Smith ***@***.***> wrote: ***@***.**** requested changes on this pull request. I probably should have been a bit more clear about where to put the email templates. When I said I wanted the email templates in the /email/layouts/ directory, I was referring to the template import path name, the path you use to reference to the template. I probably should have made this more clear, and I plan to update the documentation on our template directory schema. I'll give you a rundown on how we store our templates: Django looks at the templates folder of each app in a project and allows developers to refer to them without using a relative directory, like for instance, the template with the path /app/templates/app/pages/index.html can be referred to as /app/pages/index.html. The reason why the front-end templates are in an extra /app/ folder is to create a separation of concerns. If we have all of our templates in the base template folder, we would run into name collisions and it would be, in general, very messy. When we need templates for other things, like emails, we would have another folder called email in our /app/templates/ folder. The folder structure could probably follow in the footsteps of our app templates, with the whole components layouts pages schema. pages in this case could be renamed to something more sensible like emails. Our templates usually also extend from a base template to reduce code duplication on things like headers and footers. In the case of emails, our base template would most likely have a header and a signature at the end. This template would sensibly go in the /emails/layouts/base.html *template* directory. I hope this clears any confusion. ------------------------------ In ratatoskr/app/urls.py <#118 (comment)> : > @@ -14,6 +14,7 @@ path('schedule/<schedule:schedule>/create-timeslots', views.create_timeslots, name='create-timeslots'), path('schedule/<schedule:schedule>/<datetime:date>/reserve/<timeslot:timeslot>', views.reserve_timeslot, name='reserve-timeslot'), path('schedule/<schedule:schedule>/<datetime:date>/view/<timeslot:timeslot>', views.view_reservations, name='view-reservations'), + path('confirm/<int:reservation>', views.confirm_reservation, name='confirm-reservation'), You should probably use the new model URL converters. We have them for Schedule, TimeSlot, and Reservation. These URL converters allow us to eliminate that one line of code used for fetching the data from the database. You can look at how these converters are implemented in the app.converters module. In this case here, you would change the <int:reservation> to <reservation:reservation> to take advantage of the URL converter. — Reply to this email directly, view it on GitHub <#118 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADBZIJ6XASS2UKEN6432U4DVAOJN5ANCNFSM5Q7AD3JA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: <worcestertechnicalhighschool/ratatoskr/pull/118/review/913669066@ github.com>

-- JEFF LEBOEUF, MIS *TEACHER, PROGRAMMING AND WEB DEVELOPMENT* *WORCESTER TECHNICAL HIGH SCHOOL* ONE Officer Manny Familia Way, WORCESTER, MA 01507 *C:* 774-239-5973*E:* ***@***.*** ***@***.***>

…

-- * * *This is an email account managed by the Worcester Public Schools, Worcester, MA.  This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify the sender.*

[JackRichard889]

Fixed the issues with the email templates and the URL for confirmation. Also added cancellation URL to close #120. Didn't have time today to convert primary keys to UUIDs for reservations. There were some issues with using custom converters with the UUID data type... Good luck

[seamussmith]

Looks good. I can implement the new converter logic myself.