The one downside of skipping the template page is that you no longer
get such strong confirmation that you’ve picked the correct template.
You still see the preview of the template, but it’s further down the
page, and the name of the template has disappeared.
This commit adds the name of the template to the page title, to:
- have some continuity from the previous page
- make it easier to double-check you’ve chosen the correct template
If you only send messages then there’s no longer much point in the
template page. It now, for you, only has one action – ‘Send’.
This commit changes the journey for these users so they go straight from
clicking the name of the template to the page where you enter the phone
number or email address.
This is better because it reduces the number of steps a user has to
click through to send a message.
This journey is what we were previously calling ‘basic view’. But this
changes makes it automatically available to anyone who would benefit
from it. It removes the complexity of:
- having to opt in to basic view at a service level
- having to choose on a per-user basis who has basic view
- understanding the nuance between basic view and only choosing the
‘Send messages’ permission
Users who will still see the template page are:
- those who can edit templates – they need the ‘edit’ link
- users with the manage API keys permission – they need a place to get
the template ID
‘Upload recipients’ and ‘Send to one recipient’ have always been
slightly clunky phrases.
Now that basic view jumps straight into the ‘Send to one recipient’
flow there’s no way for users to get to the ‘Upload recipients’ flow.
By adding a link to it from the ‘Send to one recipient’ flow it’s
possible for users of basic view to access it.
But we don’t want to introduce too much inconsistency between basic view
and admin view because users will be migrating from one to another. They
might also be talking to their manager, who wouldn’t be able to tell
them where to click if they were looking at two completely different
interfaces.
This also means that we can keep the left-hand navigation in basic view
nice and simple with the two options (‘Templates’ and ‘Sent messages’),
rather than trying to introduce something like ‘Send one message’ and
‘Send lots of messages’ later on.
Version 3.1.3 changed heading classes to display block - https://github.com/alphagov/govuk_elements/pull/552
This is a breaking change for us since we are using the heading classes
to make font bold - 3.1.3 adds line breaks in places where we don't want
them and causes some functional tests to fail.
Since we will be replacing govuk-elements with the new design system,
this commit pins the version of govuk-elements instead of updating all
the code to work with the lastest version.
Includes moving code that tests an API call to
update the service with the new branding to the
preview step submission.
Also includes a change to the HTTP params sent by
the set-email-branding step. Think it was missed
out of this PR:
https://github.com/alphagov/notifications-admin/pull/1843
...so was never changed to 'branding_style'.
- corrects target page for set_email_branding to
new preview step instead of itself
- removed check for helper method being called in
email page test
- updates expected result for test of global
headers to include changes to `frame-src`
- updates navigation config with brand preview page
If you have the API keys permission you can see the settings page. But you
can’t change or request stuff, like email branding. So we shouldn’t show the
link that suggests you can.
This is the existing behaviour. It’s broken by this issue in WTForms
2.2.1: https://github.com/wtforms/wtforms/issues/401
This commit hand-crafts the default value, because WTForms is ignoring
the `default` argument on the form object attribute.
Not really sure how this ever worked 🤔
