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.
There’s no need to request the page once for each message on it. Quicker
to load the page once and then loop through the messages.
Still need this as an integration test because it’s testing the ordering
and threading of the message.
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.
You’ll quite often be landing half way down this page. So the context
afforded by being able to see the phone number gives you some
reassurance that you’ve landed in the right place.
We anchor link to the relevant message in a thread. Which is good, but
it leaves the messages hard against the top edge of the viewport. This
looks sloppy. So this commit:
- makes each message focusable
- shifts the focused message with CSS to sit away from the viewport
> 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.
