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.
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.
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.
Right now showing all the pages in full is the only way we have of
showing a letter that makes sense to our users. Maybe in the future we
show some kind of truncated version, but the end of the first page is
not a good place to truncate the letter.
This commit just extracts the code for showing multiple pages from the
template view, refactors it for reuse, and includes it in the send
views.
This is a term that one of our research participants used to describe
the big bold text that starts each letter. I think it’s quite a nice
plain english term for it.
Also changes the formatting guidance to use the word heading instead of
title, for consistency.
Users might be interested in letters. And when they’re fully
available, users will probably be able to control whether letters are
on/off for their service.
Until that point, the only way of getting the feature 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.
Wording TBC.
Users might be interested in international 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.
If a service can send internationally, our CSV validation should not
catch valid international phone numbers. This means calling through
to code added to utils in:
- [ ] https://github.com/alphagov/notifications-utils/pull/156
