The email pattern looked a bit shonky when displayed in a narrower column. This
commit fixes it by making the email’s metadata (eg subject, from) into a table,
which it sort of is. This means that it is more flexible about the size of
container in which it sits.
This commit parameterises all methods in the send view so that they can send
either emails or SMS messages.
It works out what kind of message it is sending from the `template_type`
property of the template object.
This means that the `Template` util class needs to know about these properties,
which means that this commit depends on:
https://github.com/alphagov/notifications-utils/pull/2
This commit does _not_ add tests for sending emails. The existing tests for
sending SMS still pass, but actually sending emails is outside the scope of
this story.
Templates now have:
- a type (email or sms)
- a subject (if they are email templates)
We don’t want two completely separate view files for email and SMS, because they
would have an enormous amount of repetition.
So this commit adds
- different templates for SMS and email templates
- different form objects for SMS and email templates
…and wires them up.
Because we’re not showing a summary of error messages screen reader users might
take a while to discover that there’s an error on the page. Since the only
real action on a page with errors is to correct them this commit adds some
Javascript to send focus straight to the first error message on a page.
As part of https://github.com/alphagov/notifications-admin/pull/187 the file
upload pattern was changed to auto-submit once a file had been picked. The
form that was submitted was, however, missing a CSRF token, as well as a submit
button for non-JS users.
This commit makes the file upload pattern self-contained, so that it will always
include a form with a CSRF token in a hidden input and a submit button, which is
then hidden when Javascript loads.
The ‘manage templates’ page was almost identical to the ‘send text messages’
page.
This commit consolidates them into one and makes them all hang together.
Part of this means tweaks to the javascript so that files upload as soon as
you’ve chosen them.
While looking at front end performance I noticed that the GOV.UK Template CSS
and Javascript files weren’t being minified, so were being served with (for
example) lots of comments still in the code.
This changes the Gulp task from simply copying the files to also minfiying them,
where appropriate.
Because this commit’s parent added a few new images, we are now serving at
least a handful of images, therefore a few additional HTTP requests. It’s better
to combine multiple HTTP requests into one for performance reasons (up to a
point).
This commit adds an extra step to the preprocessing of SASS files which takes
any images it finds, base64 encodes them and inlines them into the distributed
CSS files.
It also modifies the content security policy to allow inline images.
This takes the original prototype version of this page, and, using the same
fake data (ie nothing is wired up):
- adds an invite users page
- adds an edit (and delete) user page
Both these pages allow the user to set another user’s permissions.
This commit adds images for the ticks and crosses, so we have control over their
appearance.
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 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
The api has now has an user/<user_id>/email-code and user/<user_id>/sms-code
This commit requires an update to the python-client. Make sure the PR for that version has been merged first and the tag push using scripts/push_tag.sh
