Each service on the list is linked to the dashboard page of the service.
The platform admin user can see/edit templates, see/invite users, see/edit service settings.
The platform admin user can not send messages, see/edit api keys and developer docs.
Would like to test something like this and see how well it works.
Intention of having this page is so:
- template IDs are discoverable (https://www.pivotaltracker.com/story/show/115404593)
- it’s obvious there’s an ‘automated’ way to send messages, as well as the CSV
way (we’ve seen people oblivious to this in research)
> If you have the Edit templates permission but not the Send messages permission, the navigation should read
>
> - Text message templates
> - Email templates
> - Letter templates
>
> The page headings should also read
>
> - Text message templates
> - Email templates
> - Letter templates
respectively
https://www.pivotaltracker.com/story/show/115488955
The same `.html` file is shared between adding a template and editing a
template.
The page heading needs to be contextual to the URL, either ‘add’ or ‘edit’.
Somewhere along the way this got lost; this commit reinstates it.
Actually this should be no op until whatever workflow will take place
in the real world is implemented.
For the moment just display flash message to say request being
processed and do nothing.
Previously the send button on the ‘Check and confirm’ page always said
‘Send x messages’, irrespective of whether you were sending emails or text
messages.
This commit makes it say one of
- Send 1 email
- Send 29 emails
- Send 1 text message
- Send 999 text messages
The template for viewing a job was not getting all the variables it needed in
order to display an email template. Hadn’t noticed this before, because email
templates require more variables than SMS templates.
This commit fixes that bug.
There is no good reason why the API should fail to create a job at this point.
If it’s returning a 404, this is an error, and we should be monitoring for it.
So we should let it raise, and throw a 500.
It’s confusing to the user to have their phone number played back to them in
a format that they didn’t enter it. We’ve seen multiple times that people enter
0781… and then don’t recognise their own phone number when it’s played back as
+44781…
The API can handle phone numbers in any format as of
https://github.com/alphagov/notifications-api/pull/134
So there is no need to reformat the user’s phone number before storing it now.
Makes uses of the additions to utils in https://github.com/alphagov/notifications-utils/pull/9
This commit strips out a lot of the complex stuff that the views and templates
in this app were doing. There is now a cleaner separation of concerns:
- utils returns the number and type of errors in the csv
- `get_errors_for_csv` helper in this app maps the number and type of errors
onto human-friendly error messages
- the view and template just doing the glueing-together of all the pieces
This is (hopefully) easier to understand, definitely makes the component
parts easier to test in isolation, and makes it easier to give more specific
error messages.
