We should standardise on <a download> rather than
<a download="download"> everywhere. The value of the download attribute
tells the browser what filename to use, but is overridden by the
Content-Disposition HTTP header. Since it’s not being used, we should
remove it for the sake of disambiguation.
If you’re using inbound SMS then I reckon it’s useful to be able to
naviagate from one message to the context in which that message sits
(ie the conversation).
This commit adds that link.
This is maybe a stopgap until we do something more like chat, where you
can reply on the same screen where you see the conversation, but maybe
it turns out we don’t want to do that – lets see how this works.
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.
‘Report’ jobs are what we used to have for one-off messages. The page
for a report job doesn’t contain any extra info from what’s on the
notification page. We will still have ‘Report’ jobs while we transition
to sending one-off messages through the API. So while we still have
these jobs, let’s hide any links to them because they’re not useful
pages.
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.
Having a file name for single messages made sense when they were called
‘Test message’. They made a bit of sense when single messages still had
a file, which had to be called _something_.
Now that individual messages don’t come from a file, and don’t land you
on a page that looks like a ‘report’.
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
