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.
`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
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.
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.
Since we’ve removed the table of notifications from the single
notification page there’s no way of knowing the status of a
notification.
This re-adds it in a way that’s similar to how it looks on inbound
messages.
The counts on the notification page will only ever show 1 thing. Which
feels like overkill, especially if you’re only sending one-off messages.
It’s also confusing when you come from the job/activity pages which
have one set of numbers to then be confronted with a different set of
numbers.
The important stuff on this page is:
- what the message was
- some meta information about it
Sorry Leo 😢
Status code was overcomplex, given how we control the inputs. Now, it
expects a single value, rather than a comma separated list, and if you
give something it doesn't expect it just returns all. Note, it won't
select the correct box - but if you've been manually editing the URL
that's your own problem ¯\_(ツ)_/¯
Also, as this page will only ever be shown from the tour (tutorial),
it doesn't need some non-help things - such as the download csv button
and associated endpoint.
