darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-08-14 23:08:07 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
c6de605311ded7a11d2d9e2d78fc6db1f3ab108a
notifications-admin/app/templates/components/email-message.html

41 lines
1.1 KiB
HTML
Raw Normal View History

Preview service name when adding a new service This commit adds a new page, which appears after a user enters the name for their new service. It shows how the service name will appear in emails and text messages. This means that the new service is not created until after they have confirmed that the name is appropriate in context. This has also involved: - visual changes to the ‘email template’ pattern, which wasn’t very refined before - removing a bunch of words from the enter service name page, because most users don’t read them, and we reckon that showing a preview is a better way of getting them to understand what is meant by service name Still to do: - validating the the generated email address for a service is unique (on the API) side - having the API return the generated email address, rather than determining it in the admin app
2016-02-18 14:54:59 +00:00
{% macro email_message(subject, body, name=None, edit_link=None, from_name=None, from_address=None) %}
Add a prototype email template If the templates page contains text messages and emails then there’s two ways it could be structured: - into two sections, all text messages first, then all emails - emails and text messages interleaved, sorted by date I think the second one is better. Imagine a situation where you mostly do emails but have a few text messages. You’d have to scroll past the text messages to get to your emails. Every time. I reckon that the most commonly accessed templates will be the most recent ones.
2016-01-13 16:27:54 +00:00
{% if name %}
<h3 class="email-message-name">
{% if edit_link %}
<a href="{{ edit_link }}">{{ name }}</a>
{% else %}
{{ name }}
{% endif %}
</h3>
{% endif %}
<div class="email-message">
Preview service name when adding a new service This commit adds a new page, which appears after a user enters the name for their new service. It shows how the service name will appear in emails and text messages. This means that the new service is not created until after they have confirmed that the name is appropriate in context. This has also involved: - visual changes to the ‘email template’ pattern, which wasn’t very refined before - removing a bunch of words from the enter service name page, because most users don’t read them, and we reckon that showing a preview is a better way of getting them to understand what is meant by service name Still to do: - validating the the generated email address for a service is unique (on the API) side - having the API return the generated email address, rather than determining it in the admin app
2016-02-18 14:54:59 +00:00
{% if from_name and from_address %}
<div class="email-message-from">
<div class="grid-row">
<div class="column-one-eighth">
<span class="form-hint">From</span>
</div>
<div class="column-seven-eighths">
{{ from_name }} &lt;{{ from_address }}&gt;
</div>
</div>
</div>
{% endif %}
{% if subject %}
<div class="email-message-subject">
<div class="grid-row">
<div class="column-one-eighth">
<span class="form-hint">Subject</span>
</div>
<div class="column-seven-eighths">
{{ subject }}
</div>
</div>
</div>
{% endif %}
Add a prototype email template If the templates page contains text messages and emails then there’s two ways it could be structured: - into two sections, all text messages first, then all emails - emails and text messages interleaved, sorted by date I think the second one is better. Imagine a situation where you mostly do emails but have a few text messages. You’d have to scroll past the text messages to get to your emails. Every time. I reckon that the most commonly accessed templates will be the most recent ones.
2016-01-13 16:27:54 +00:00
<div class="email-message-body">
Use `Template` to replace/highlight placeholders This commit brings in the `Template` util, added here: https://github.com/alphagov/notifications-utils/pull/1 It also does a fair bit of tidying up, which I’ve unfortunately squashed into this one massive commit. The main change is moving 404 handling into the templates dao, so that every view isn’t littered with `try: … except(HTTPError)`. It also adds new features, in a prototypy sort of way, which are: - download a prefilled example CSV - show all the columns for your template on the 'check' page
2016-02-08 16:36:53 +00:00
{{ body|nl2br }}
Add a prototype email template If the templates page contains text messages and emails then there’s two ways it could be structured: - into two sections, all text messages first, then all emails - emails and text messages interleaved, sorted by date I think the second one is better. Imagine a situation where you mostly do emails but have a few text messages. You’d have to scroll past the text messages to get to your emails. Every time. I reckon that the most commonly accessed templates will be the most recent ones.
2016-01-13 16:27:54 +00:00
</div>
</div>
{% endmacro %}
Reference in New Issue Copy Permalink