Since broadcast services can only have one type of template we probably
don’t need to disambiguate what kind of template you’re creating.
And you’ve just come from a page where the button says ‘New template’,
without the choice of radios after, so it’s nice for the page title to
match that.
Adds the extra text added to each checkbox label.
It's a copy of the text of the link in the same
list item which does add a lot of duplication to
the test data.
This reformats a lot of the test data, stacking it
to separate out the duplicate items.
This conditional comes from before we launched the letters feature.
Since we were only giving the letters permission to teams that we were
inviting, we didn’t want to confuse new users by mentioning letters.
Nowadays all new services will have the letters permission, so this
check is redundant.
Adds the extra text added to each checkbox label.
It's a copy of the text of the link in the same
list item which does add a lot of duplication to
the test data.
This reformats a lot of the test data, stacking it
to separate out the duplicate items.
This commit removes the code the puts areas into the session and instead
creates and then updates a draft broadcast in the database.
This is so we can avoid session-related bugs, and potentially having a
large session when we start adding personalisation etc.
Once a broadcast is ready to go it is set to `broadcasting` straight
away with no approval. We’ll revisit this as we learn more about how
users might want to manage who can create and approve broadcasts.
The tests are a bit light in terms of checking what’s on the page, but
clicking through the pages is probably good enough for now.
We’re not going to have an API for sending broadcasts at the moment, so
you don’t need the template ID for anything.
Broadcast also won’t contain personal information, or tokenised links,
etc, so there’s no need to redact them after sending.
Removing this things means the interface is less cluttered.
These are just so we have some pages to click through for now. They
don’t use real templates, or any of the broadcast stuff from the
database.
But I think it’s useful to get some skeleton pages in first so that we
can see the map etc working in production, then build on that, without
having to do it all in one mega PR.
For that reason there are two short term things I’ve done in this commit
which should be revisited soon:
- no tests for the endpoints
- data about which areas are selected is stored in the session
At the moment this won’t look like much, but it will let us do an
end-to-end run of adding a broadcast template.
At the moment all you can do with a broadcast template is edit it, so
there’s no ‘Send’ link on the page.
At the moment the page is the same as for text message templates,
except:
- different H1
- no guidance about personalisation, links, etc (until we decide how
these should work)
For now you won’t be able to really create a broadcast template, because
the API doesn’t support it (the API will respond with a 400). But that’s
OK because no real services have the broadcast permission yet.
This required a bit of refactoring of how we check which template types
a service can use, because there were some hard-coded assumptions about
emails and text messages.
This involves three changes which broke our code.
To validate email addresses, the optional dependency `email-validator`
must be installed<sup>1</sup>. But since we don’t use WTForms’ email
validation, we shouldn’t need to subclass it – it can just be its own
self contained thing. Then we don’t need to add the extra dependency.
When rendering textareas, and extra `\r\n` is inserted at the beginning
<sup>2</sup>. Browsers will strip this when displaying the textbox and
submitting the form, but some of our tests need updating to account for
this.
The error message for when you don’t choose an option from some radio
buttons has now changed. Rather than just accepting WTForms’ new
message, this commit makes the error messages like the examples from
the Design System<sup>3</sup>. By default it will say ‘Select an
option’, but by passing in an extra parameter (`thing`) it can be
customised to be more specific, for example ‘Select a type of
organisation’.
***
1. https://github.com/wtforms/wtforms/pull/429
2. https://github.com/wtforms/wtforms/issues/238
3. https://design-system.service.gov.uk/components/radios/#error-messages
We had 7 classes in _grids.scss named `.column-...` which were being
used to give a certain column width. These worked by using `@include
grid column()`, which is now deprecated.
`.column-whole` and `.column-three-quarters` can be removed and replaced
with `govuk-grid-column-full` and `govuk-grid-column-three-quarters`
respectively. The other column classes don't have a direct replacment in
GOV.UK Frontend. To get round this, we overwrite the `$govuk-grid-width`
SASS map in `extensions.scss` to add in extra widths, then use this with
the `govuk-grid-column` mixin to create new classes in for our custom
widths in `_grids.scss`
This replaces the buttons that aren't part of a macro and that we don't
need to write additional styles for with their govuk-frontend equivalent.
There were some links that were styled to look like buttons, so these
have also been replaced with the new govuk-frontend macro.
There was one button on the `choose-account.html` template that was in a
section of code that was never reached - this has been deleted.
As per https://www.pivotaltracker.com/story/show/170796514 we want to make the delete template confirmation dialog box more consistent and clear.
The API has been updated with a new endpoint that only returns the last-used date, this date is more accurate since it goes to the ft_notification_status table, if the notification table is empty.
make sure everything is using the `nl2br` formatter that properly wraps
it in markdown to keep everything sanitised nicely. Also write a couple
of tests
This stops most instances of the fixtures which return sms senders,
email reply to addresses or letter contact blocks from being called as
if they were functions in the tests by replacing them with functions
which return the same results.
This change allows a couple of fixtures which are now longer used to be
deleted.
We were using user fixtures in a lot of parameterized tests, but this is
no longer allowed in Pytest 5. To avoid having to split up the parametrized
tests (which would make the test files a lot longer and slightly more
difficult to read) this commit creates functions which return various types
of user json so that we can use these as the test parameters instead.
Since we’re only showing this page to team who are using the API we
don’t have to worry about explaining what’s going on in terms of the
spreadsheet any more.
This makes the page simpler.
We introduced the ‘breaking change’ page[1] partly to help teach people
about the relationship between the placeholders in their template and
the data they were providing. Data can be provided either by API or by
uploading a spreadsheet. The users who we struggled to communicate this
relationship to were the ones using the upload a spreadsheet feature.
We made two changes to the context of this feature:
1. Around the same time we introduced the interactive tour[2], which
ultimately proved to be the thing that helped people understand the
relationship between the data they were providing and the
placeholders in the template.
2. We introduced a way for people to send one-off messages without
using the API or uploading a spreadsheet[3]. So for this page to say
that you’ll need to update a spreadsheet or change an API call if you
change the placeholders in your template is no longer accurate.
Therefore I think it makes sense to only show this page to teams who are
using the API to send messages. The best proxy we have for that is to
look at whether they’ve created any API keys.
***
1. https://github.com/alphagov/notifications-admin/pull/631
2. https://github.com/alphagov/notifications-admin/pull/613
3. https://github.com/alphagov/notifications-admin/pull/1293
We mostly rely on the API returning a 404 to generate 404s for trying
to get things with non-UUID IDs. This is fine, except our tests often
mock these API calls. So it could look like everything is working fine,
except the thing your passing in might never be a valid UUID, and thus
would 404 in a non-test environment.
So this commit:
1. uses the `uuid` URL converter everywhere there’s something that looks
like an ID in a URL parameter
2. adds a test which automates checking for 1.
HighlightTags was bad because:
- we haven’t called placeholders ‘tags’ for a long time
- it also does resizing of the `<textarea>`, not just highlighting the
placeholders
of course it's logged in, it's a platform admin
also, reduce use of the `client` fixture in test_platform_admin
(replace it with platform_admin_client)
