‘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.
Because:
- drawing things in CSS is fun
- when we have inbound messages, having a tail pointing the other way
will help differentiate which messages are inbound
Things we don’t do with SMS messages any more:
- put paragraphs in them (we use `<br>` tags instead, to allow for
multiple linebreaks)
- pick them using radio buttons
- render the template’s name as part of the template
- render the phone number that the message will be sent from as part of
the template
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.
People are going to hammer through this form _fast_, so not making them
click into the form field on every page load is a nice enhancement.
Reuses the code written to do this on the page where you enter your
verification code.
You might need to scroll this page quite a lot to see where a
placeholder appears in your template – especially if you have a long
email or letter.
One of the things I’m trying to stop happening so much is a lot of
scrolling back and forth. This would happen if you were scrolling down
to see the placeholder, then back up to fill in its value.
So this commit makes the textbox ‘sticky’, ie it always stays at the top
of the viewport, even when you scroll down. This lets you see the
placeholder and the textbox side by side, no matter how long the
template is.
The code to do this mostly comes from the GOV.UK Frontend Toolkit
(documented here: d9489a9870/docs/javascript.md (stick-at-top-when-scrolling)).
I had to add some extra CSS to make it look good when it overlaps the
content of the page, which the GOV.UK Frontend Toolkit implementation
doesn’t really anticipate.
