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.
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.
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.
There’s a lot of repeated code in our Jinja templates for the settings
page.
We already have a `boolean_field` component, but it’s not used anywhere
(it was just lifted from Digital Marketplace).
So this commit changes the `boolean_field` component to be useful for
our on/off use case, and wires it into the settings page.
Users might be interested in inbound SMS. And when it’s fully
available, they’ll probably be able to control whether it’s on/off for
their service.
Until they point, the only way of getting it is to ask us. So let’s make
an in-the-meantime page that directs them to ask us, from the place
where they’d be able to do it themselves.
Cool URIs don’t change 😎https://www.w3.org/Provider/Style/URI
We still have links to `/feedback` in our emails. These will live in people’s inboxes forever.
Only services that have inbound SMS turned on should be able to see the
dashboard and ‘Received messages’ page.
There’s probably a cleaner way (decorator) of doing this permissions
stuff, but I think it can wait until we ship this.
This commit adds two things:
a section on the dashboard to show how many inbound messages the
service has received in the last 7 days, and how recently an inbound
message has been received
---
Doesn’t show the contents of any messages, just like how the rest of the
dashboard is an aggregation, never individual messages.
a page to show all the inbound messages the service has received in
the last 7 days
---
This shows the first line of the message. Eventually this will link
through to a ‘conversation’ page, where a service can see all the
messages it’s received from a given phone number.
CQC is an executive non-departmental public body, sponsored by the
Department of Health.
They have asked to be allowed to register for Notify using the
`cqc.org.uk` and `digital.cqc.org.uk` domains. We know that this really
is there domain because it’s linked to from here:
https://www.gov.uk/government/organisations/care-quality-commission
There’s no need to see the ‘Report’ page for a one-off message – pretty
much all the info about the notification is there on the page. And
‘Sent from _Report_’ looks weird.
We should display it more like an API call instead.
If clicked you will be prompted to enter a sms sender number, when setting the permission on or off.
Team members will always be able to see the number, but will only be able to change it if the inbound_sms permission is off.
