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.
If a invited user accepts a cancelled invitation they are directed to a page telling them the invitation is cancelled.
Without this they were able to register and were added to the service.
I’d like to see if we can get away without this now that the page updates. In
research the ‘We’ve started’ part of the message confused people, especially
when they’d only sent one message.
This is a first go at having the job page update without refreshing.
The approach I’ve taken is to do all the rendering of HTML on the server side,
rather than use a Javascipt templating engine like mustache. This ensures that
we don’t have to maintain two sets of templates.
So the approach is to split the job page into partials. These partials can then:
- be included in the job page to render the whole page
- be rendered indivudually and then returned as a blob of HTML inside a JSON
response
Then I’ve added a Javascript module which looks for areas of the page that should
be reloaded. For each area of the page it will poll a URL and re-render that
section of the page when it gets new HTML. It implements some throttling so that
API calls will never happen more frequently than 0.67 times/second.
register. On succesful register and verfication they
will be added to service and forwarded to dashboard.
Nothing is done yet with the permissions requested in the
invite to the user.
CSV files currently have ‘to’ as the recipient column. This is changing in
https://github.com/alphagov/notifications-api/pull/109
The admin app also has to validate that the CSV files have the right columns,
because the API expects any CSV that it’s given to have been checked (also we
want things to actually work).
This commit is the minimum code change needed. In the future it should reuse
the same code as the API for processing CSV files. This will need more thinking.
