We changed the schema used by the endpoint that searches for
notifications by recipient. So the admin app was looking for the wrong
thing in the JSON.
This is hard to catch in tests because it relies on our fixtures
matching what the API really returns.
This commit fixes the code to use the correct key to lookup the template
content from the JSON.
This also exposed the fact that we weren’t passing in the
personalisation any more (perhaps got lost in the re-reverts somehow)
so users were only seeing the template in the inbound view, not the
full message content.
If sending SMS is disabled for a service, it should not be possible to
add or modify SMS templates. If a user tries to do this, they should see
a different page with a link to go back. The same thing should happen
with email templates.
Platform admins can now disable sending sms for a service. If sending
sms is disabled, this will also hide all the other sms options in the
Settings table.
Platform admins can now disable sending of emails for a service. If
sending emails is disabled, this will also hide the option to change the
Email reply to address.
We’re frequently ending up with mismatched page titles on our pages
because:
- they’re hard to spot in the browsers tab bar
- new pages are often created by copy pasting old ones
It would be hard to write some kind of macro that spat out the h1
and the page title because they go into different blocks in the
parent template.
Instead, we can catch these mistakes by testing for them. Going
forward we should be using the `client_request` fixture for testing.
So it makes sense to put the page title test in here so that we
get it for free in every test – same way we do for testing response
codes.
fixup! Test for page titles in client request fixture
`test_utils.py` is actually a file for testing some utils, not
some utils for testing.
Test helper functions and fixtures are better placed in conftest,
and also means that we can use them in conftest.
If a template has the `redact_personalisation` flag set, then this
commit removes the personalisation from the notification before
rehydrating the template.
We’re doing this because we have a need to not show things like one time
passwords or two factor codes when we show the content of messages.
By passing through empty personalisation, and the `redact_missing` flag,
the `Template` instance will make use of the work done in:
- [x] https://github.com/alphagov/notifications-utils/pull/171
The following errors may happen:
* Number outside of service if service in trial mode
* Message too long for sms
* Service over daily limit
We need to handle these. They only return on send, rather than in a
separate validation step (for now).
We’ve made a few changes to the tour recently, without changing the
help text on the left hand side of the screen. So the stuff you see on
the right side of the screen doesn’t quite sync up any more.
This commit adds an extra, introductory page that just shows the
template and a next button, which better matches the ‘every message
starts with a template’ help text.
Works similarly to the delete template flow, because it’s a destructive,
one-way action.
Not on the edit template page, because it’s not something you want to be
considering every time you’re editing a template. And we saw that people
couldn’t find the delete button when it was on this page.
Adds a bit more CSS for the `dangerous` banner type, because the content
here is quite complicated. Breaking it into a list helps, but the
spacing didn’t look right, so needed some tweaking.
Can ship independently of the code that shows the redaction, but needs
the API first.
When we do a `POST` we almost always do a redirect straight afterwards.
`client_request` understands this, and expects a `302` by default.
However, if the `_follow_redirects` flag is set the status code returned
is that of the subsequent request – normally a `GET`, itself returning
`200`. Therefore the default expected response code would need to be
overridden.
Overriding this repeatedly would get pretty boring. Better to do it once
inside the fixture.
For some reason:
- notifications sent from CSV files have the recipient as part of the
personalisation
- notifications sent via the API don’t have the recipient as part of the
personalisation
I’d only tested it locally with CSV-sent files so didn’t spot this. The
`conftest.py` fixtures we set up like the API already, but we didn’t
have an explicit test.
This commit adds a method to append the recipient to the
personalisation, so we can populate the template with it.
There are lots of services that only send emails, or only send text
messages. For these services, being able to filter the list of templates
but type is pointless – it won’t cut the list down at all.
This commit adds some logic to only show the navigation if the service
has some variety of template types.
When users are trying to find a template there’s a fair chance that they
know whether or not it’s an email/text message/(letter) that they’re
looking for.
Making them scroll past a whole bunch of templates of a different type
means it will take them longer to find the template they are looking
for.
We already have search on the templates page, but this is only good for
where they can remember the name of the template. This will be
sometimes but not always.
This commit adds some navigation to filter down the list of templates to
only show one type at a time. By default it will show all templates. It
adapts the pattern we use for filtering notifications by
sending/failed/delivered, but without the counts of how many things are
in each bucket (I don’t think there’s any value in knowing you have X
text message templates; on this page you only really care
about the one template you’re looking for).
_Note: required re-arranging the functions in `templates.py`. The route
for `/template/:uuid` needs to come before the route for
`template/:string` otherwise Flask tries to interpret a template’s ID
as its type.
Bug was happening because:
```python
bool(list())
>>> False
```
```python
bool((item for item in list()))
>>> True
```
i.e. generator expressions cast to boolean are `True`, even if they’re
empty – Python doesn’t evaluate them.
This was causing the functional tests to fail because it was taking too
long for any table rows to appear on the page.
We’ve removed the template on the jobs page, so you can no longer see
which template a job is about to be sent with.
This is removing information which might enable you to undo a costly
mistake.
I don’t think we need to bring back the whole template – giving its
name, and a link to it meets the need just as well.
Showing the template on the job page was semi-useful when you couldn’t
see the contents of each individual message. It was still a bit weird
because it just showed the template, never the actual messages that
went out, with the placeholders.
Now that users can click through to see individual messages, and can see
a short preview of the content on each row I think we can safely lose
the template preview on this page.
In tables where we show rows and rows of information we used to give
some meta information about the notification, or at least as much as we
could give in the very limited space available.
This information is now on the notifications page, so the information we
show in these tables should just be whatever helps users identify the
right message. I reckon that this is:
- the content of the message for text messages
- the subject for emails and letters
This also makes these pages consistent with:
- the inbound SMS page
- the way the people’s inboxes work for their text
messsages/Whatsapps/emails
For consistency’s sake this makes the job page work the same way. It may
be slightly less useful here because on the job page every message is
sent from the same template, so will have broadly the same content.
We’ve had a few teams talk about wanting to go back and check what their
users are sending out, including the content of any placeholders.
We already provide this functionality through the API, this commit makes
it the default in the admin app too.
We couldn’t do this before because we didn’t have the individual
notification page.
It’s better to do this by re-hydrating the template than pulling the
content from the API, because things like letters have multiple areas
of content – this is more complex than what we can get from API at the
moment.
