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 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.
If a notification has been sent from a job then that’s important context
to know about it. So we should surface that information on the page.
It also gives users an easy way of going back, if that’s the page
they’ve come from.
The meta info about a notification (who sent it, when they sent it)
won’t ever change, so there’s no need for it to reload it using AJAX.
Putting it above the message and under the `<h1>` makes it match how
this information is displayed on the job page.
On the job page this information is bold, but visually the job page is
using too much bold now (nothing is emphasised/differentiated if
everything is bold). So this commit also makes this line of info regular
on both the notification and job pages.
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 removed the notifications table from this page we need a
different way of showing who the message was sent to.
Our `Template` classes already have a way of doing this, and we have a
flag to switch this on (which is what this PR changes).
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 😢
completely mimicks the job status page, and as such, all the code and
templates have been taken from the job page. This page performs
exactly the same as the job page for now
* total, sending, delivered, failed blue boxes (though they'll just
read 0/1 for now.
* download report button (same as with job download, except without job
or row number in file)
* removed references to scheduled
* kept references to help (aka tour/tutorial) as that'll eventually
change over from a job to a one-off too
