Adds a new endpoint that works like view template/view preview of
letter, so that this page works the same way it does for emails/text
messages (ie showing the full content of the message, including
personalisation).
We’re not worrying about redaction in letters for now.
The status won’t ever change from sending for letters. For now at least.
And even when we do come up with more useful statuses I’m not convinced
it’s useful to expose them to our admin users.
A more useful piece of information to show is when we think the letter
will be delivered.
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.
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
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.
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.
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 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.
> Once an inbound message has been received, there should be a way to
> see the other messages in the system from the same service to the same
> number. Both in and outbound. Nice inbox/whatsapp stylee view or some
> such. This way the context of the reply is understood.
>
> Initially will only see the outbound template, not the actual message,
> but we’re going to change this for the rest (soon), so that you can
> always see the full message for all outbound.
This commit adds two things:
a section on the dashboard to show how many inbound messages the
service has received in the last 7 days, and how recently an inbound
message has been received
---
Doesn’t show the contents of any messages, just like how the rest of the
dashboard is an aggregation, never individual messages.
a page to show all the inbound messages the service has received in
the last 7 days
---
This shows the first line of the message. Eventually this will link
through to a ‘conversation’ page, where a service can see all the
messages it’s received from a given phone number.
If clicked you will be prompted to enter a sms sender number, when setting the permission on or off.
Team members will always be able to see the number, but will only be able to change it if the inbound_sms permission is off.
> Service teams that use the admin interface often need to know the
> outcome of a message... at the moment they have to page through all
> the results in the activity stream. They should be able to find
> notifications by email address or phone number.
– https://www.pivotaltracker.com/n/projects/1443052
This commit adds an additional query string parameter (`to`) to the URL,
which users can use to filter down the list of notifications.
It:
- takes the status into account
- doesn’t update the counts based on the search term (in reality each
service will only send a handful of notifications to one person in any
7 day period)
In other words the funnel that filters down the notifications looks
like:
> all notifications for service → only failed → only to this phone
> number
If a service can send internationally, our CSV validation should not
catch valid international phone numbers. This means calling through
to code added to utils in:
- [ ] https://github.com/alphagov/notifications-utils/pull/156
The breaking change page wasn’t properly accounting for the fact that
letter recipients span multiple columns – it was assuming they’d only
take up one column like they do for email and SMS.
This commit fixes:
- the number of column headers (A, B, C, …) to be correct
- the count of columns (you will need X columns in your file) to be
correct
It then parameterises the test to look at a case where a recipient is
in one column (email) and multiple columns (letter).
Tests assumed that the API returns the template `id` as part of the
object. It doesn’t – it returns it as the key used to look up the
object. The `id` was missing from the transformation into the format
used by the front end.
For some reason Flask is fine building the URL with `template_id=None`,
but obviously this doesn’t generate a valid link.
