When you edit a template, you’re probably going to do something with
it straight afterwards, eg send yourself a test.
We could make it easy to find the template you’ve just saved by putting
it at the top of the pile. This gets confusing for other reasons (order
of templates will constantly shift about).
So this commit changes the flow to take you to the single page for the
template you’ve just edited.
For the button on the check page, we need to be able to say ‘1 text message’ or
‘55 emails’. We already have the logic to do this on the dashboard (101 text
messages sent), and it’s already in a component. So this commit makes the check
page use the same component.
Row-level errors are:
- bad phone number/email address
- missing data
I think it’s distracting to show these on the page if there’s something more
fundamentally wrong with the file, eg placeholders don’t match.
So this commit makes sure that these error messages are only displayed when the
top-level error says ‘There is a problem with your data’
This commit rearranges the CSV errors (again) to make them geared towards
teaching you how to match placeholders to the column headers.
So the order of errors now is:
1. No phone number/email column
2. Column headers don’t match placeholders
3. Missing or bad data
4. Trial mode
5. Daily limit reached
This depends on:
- [x] https://github.com/alphagov/notifications-utils/pull/39 for 1.
Now that the example on the breaking changes page looks more like a spreadsheet,
we should do the same thing for the downloadable example on the send page.
When a user adds or removes placeholders in their template we should consider
this a ‘breaking change’ and warn them accordingly.
Implementing this mostly relies on using
https://github.com/alphagov/notifications-utils/pull/37
Temporarily storing the new template until the user confirms that they want to
make the changes in done using hidden fields. This is a bit hacky, but the
complexity of making sessions interact with WTForms was just too much to handle.
This commit also changes the example spreadsheet that we show on this page to
look more like a spreadsheet.
While battling the bank holiday traffic on my way home this evening I realised
why looking at the job page was causing lots of 403 errors in the Chrome
console (a spike which was reflected on the Graphite screen).
There is a separate `.json` endpoint for getting updates to a job. This enpoint
did not have the `admin=True` option set in its permissions decorator. So when
viewing a service as a platform admin you could see the page, but not receive
any AJAX-powered updates to it.
_The code for this is quite hacky and light on tests. But I’d really like to get
it in the app for the research tomorrow to see how well the feature works._
This commit changes the tour from being a set of static screens to some help
which guides you through the process of sending your first test message.
The theory behind this is that what users are really struggling with is the
concept of a variable, rather than the relationship between the placeholders and
the column headers. And like learning to program, the best way to learn is by
taking an example and modifying it to your own needs.
This means that when someone adds their first service we set them up an
example email template and an example text message template. Then there is a
guided, three step process where _all_ the user can do is send a test message to
themselves.
Once the message is sent, the user still has the example templates which they
can edit, rather than having to remember what they’re supposed to be doing.
If you’re downloading a bunch of reports from your jobs then it’s useful to be
able to differentiate between them. This commit makes it easy to do so by naming
the file with:
- the name of the template
- when the job was created
