> 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.
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
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.
‘One-off’ is a bit wooly. Feels like our name for the thing. ‘Send to
one recipient’ matches ‘Upload recipients’.
This also means making the `<h1>` on job page ‘Report’ for one-off
messages. It doesn’t make sense to call the feature ‘send to one
recipient’ when we’re not using the language of one-off any more.
It’s a confusing proposition to have two features which are almost
identical. Even differentiating between them in the template menu would
be tricky.
I think the better thing to do is rename the whole feature to ‘send
one-off message’.
Then if someone wants to use there own phone number or email address,
give them a quick shortcut to doing that, once they’re in the flow.
In the background this reuses the ‘send yourself a test’ code, but
the user is never aware that they’re going through a different route
to send an individual message. So the proposition stays nice and clean.
We have some fairly complicated nested if statements in our Jinja that
decide what the page titles should be. It’s only going to get more
complicated with the send individual message routes.
So this commit:
- moves the logic from Jinja to Python
- adds tests to check things are working as expected
- sets the page titles to the right thing for each flow
It would be annoying to get all the way to the end of the flow and get
told that the phone number or email address you entered isn’t valid.
So this commit reuses the existing WTForms objects that we have to do
some extra validation on the first step in the send one-off message
flow. It also accounts for international phone numbers, if the service
is allowed to send them.
It doesn’t reject other people’s phone numbers if your service is
restricted, because I think it’s better to let users play with the
feature – it’s good for learning.
This commit adds an extra, initial, step to the ‘send one-off message’
flow to ask for a phone number or email address. This is the first pass
at making a feature which caseworkers or similar could use Notify to
send individual messages while they’re working a case.
Because manually editing the URL isn’t a great user interface, this
commit adds a search field to do this on the user’s behalf.
For this pass at the story it doesn’t do any validation – the user will
just get no results if they search by something which isn’t a phone
number or email address.
If the user navigates to a different ‘bucket’ of notifications (eg
delivered, failed) then the search term is reset, because they’ve
changed the filter which is at a level above the search term.
> Service teams that use the admin interface often need to know the
> outcome of a message... at the moment they have to page through all
> the results in the activity stream. They should be able to find
> notifications by email address or phone number.
– https://www.pivotaltracker.com/n/projects/1443052
This commit adds an additional query string parameter (`to`) to the URL,
which users can use to filter down the list of notifications.
It:
- takes the status into account
- doesn’t update the counts based on the search term (in reality each
service will only send a handful of notifications to one person in any
7 day period)
In other words the funnel that filters down the notifications looks
like:
> all notifications for service → only failed → only to this phone
> number
This commit adds a route which is identical to send yourself a test, but
with its own endpoint. This will let us add a slightly different
‘send a one-off message’ flow. This commit just adds the route though,
and makes sure that the tests pass for both routes.
It’s annoying for tests to pass locally because the template preview app
is running locally, but fail on Jenkins because the template preview app
doesn’t exist.
This commit changes it’s hostname to use a dummy port in tests.
Previous implementations of this functionality mutated the base form
class, which broke a bunch of stuff.
I want to make sure that getting this form for one placeholder doesn’t
change other forms that have already been instantiated for other
placeholders.
Mutation is scary.
Because we put the step in the URL, users could:
- skip ahead to a later step
- navigate to a step which doesn’t exist (ie an index greater than the
number of placeholders)
This commit adds some checks to do the sensible thing in the unlikely
event that either of these situations occur.
Calculating the number of pages in a letter is quite slow. And the send
yourself a test pages need to load _fast_. Since filling in placeholders
is very unlikely to change the number of pages in the resultant letter,
it’s pretty safe to cache that count, and makes the subsequent pages
load a lot faster.
The send yourself a test feature is useful for two things:
- constructing an email/text message/letter without uploading a CSV file
- seeing what the thing your going to send will look like (either by
getting it in your inbox or downloading the PDF)
- learning the concept of placeholders, ie understanding they’re thing
that gets populated with _stuff_
The problem we’re seeing is that the current UI breaks when a template
has a lot of placeholders. This is especially apparent with letter
templates, which have a minimum of 7 placeholders by virtue of the
address.
The idea behind having the form fields side-by-side was to help people
understand the relationship between their spreadsheet columns and the
placeholders. But this means that the page was doing a lot of work,
trying to teach:
- replacement of placeholders
- link between placeholders and spreadsheet columns
The latter is better explained by the example spreadsheet shown on the
upload page. So it can safely be removed from the send yourself a test
page – in other words the fields don’t need to be shown side by side.
Showing them one-at-a-time works well because:
- it’s really obvious, even on first use, what the page is asking you to
do
- as your step through each placeholder, you see the message build up
with the data you’ve entered – you’re learning how replacement of
placeholders works by repetition
This also means adding a matching endpoint for viewing each step of
making the test letter as a PDF/PNG because we can’t reuse the view of
the template without any placeholders filled any more.
The CSV upload route has always quietly ignored excess personalisation.
We changed the API to do the same here:
https://github.com/alphagov/notifications-api/pull/853
This means that removing a placeholder from a template is never a
breaking change, because the data that you were providing to populate it
is now just ignored.
So we don’t need to show the interstitial page in this case.
