If a user puts a linebreak in an SMS template then the recipient will
see these linebreaks on their phone. So when we show a preview of an SMS
template, it should have linebreaks in it.
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
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
A previous commit removed these to differentiate between this page and the
manage templates page. It turns out that we do want previews on this page
because:
- the users for the two pages might be different—they might only be allowed to
do one or the other depending what permissions they have
- it’s useful to see what the placeholders in the message are before uploading
a CSV, to make sure the CSV has the correct column headings
This commit re-adds the message preview with a simpler UI. Discussed with
@antimega and we both agreed that the speech bubble tails on the messages should
go.
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.
Message status was almost identical to banner, visually and semantically.
This consolidates the two into one component.
This means adding an extra parameter which controls whether or not the banner
has a tick (with and without a tick are the only two variations currently).
Having the full history of the message is more information than is necessary.
We should only show what stage the message is at, and the time that it reached
that stage.
We can do research later on to find out if users understand or care about the
different stages.
Since GOV.UK Elements is versionned now it makes sense to bring it in as a
dependency. This enforces a separation between what generic stuff we’re using
from Elements and what is specific to our app.
The benefit is that when the generic stuff changes it will be easy to bring
those changes in.
This commit also bumps GOV.UK frontend toolkit to the latest version (v4.5.0).
