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.
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 😢
We have a page for individual notifications now.
On the job and activity pages each row of the table represents an
individual notification. So it makes sense for these things to be linked
together, so that a user can navigate from one to the other.
This will make more sense once we make some more changes to the
individual notification page.
We’re showing these kinds of logos bigger as of this PR:
https://github.com/alphagov/notifications-utils/pull/170
If we don’t increase the resolution of the asset to be bigger then it
will look blurry.
New image is `108px` high, which is `2 * 54px`, in order for it to look
as good as possible on retina screens.
Generally, bigger click areas are better[1], as long as they don’t cause
ambiguity.
This commit expands the clickable area of links to templates to include
hint text underneath which states the type of template.
1. https://en.wikipedia.org/wiki/Fitts%27s_law
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.
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
Normally, fixed position elements are positioned at `top: 0`.
The code that stops them from overlapping the footer does so by:
- setting the position to absolulte
- setting `top` to a calculated value (eg `1500px`) which makes it sit
above the footer
The problem is caused because we’re animating `top`, so when scrolling
back up the page elements are getting animated from `1500px` to `0px`,
ie flying up from the bottom of the screen.
The transition between something being static in the page and fixed to
the top of the viewport is a bit jarring.
This commit adds a bit of animation so that, as elements become fixed,
they appear to catch up with the scrolling of the page.
Not good to be storing people’s phone numbers in browser autocomplete.
And increases the chance of accidentally sending the wrong thing to the
wrong person.
Serializing the search box form is bad, because the AJAX thing submit
any changes that the user makes to the contents of the box. This results
in unexpected behaviour.
See parent commit for the reason we’re doing this.
Currently our AJAX requests only work as `GET` requests. So this commit
does a bit of work to make them work as `POST` requests. This is
optional behaviour, and will only happen when the element in the page
that should be updated with AJAX has the `data-form` attribute set. It
will take the form that has the corresponding `id`, serialise it, and
use that data as the body of the post request. If not form is specified
it will not do the serialisation, and submit as a `GET` request as
before.
Phone numbers and email addresses are showing up in URLs where we let
users search for sent notifications by phone number or email address.
`GET` requests put the form data as a query string in the URL. This is
problematic when people are searching by a recipient’s phone number or
email address, because the URL may show up:
- in our server logs
- in our analytics
- in the user’s browser history
This is bad because these are all places where we don’t want
people’s personal information. It’s not too bad when this is happening
a handful of times. But it would be bad if we kept aggregating this
information because it would allow us to track users across services.
So, while it’s not especially RESTful, it’s better for the search form
to submit as a `POST` request. This way the phone number or email
address goes in the body of the request and does not show up in the URL.
