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.
The template was displaying raw, eg ‘Hello ((name))’
This commit changes it to use the `.formatted_as_markup` property so the
template is rendered with:
- the placeholders as blue lozenges
- the service name prefixing the message
**Problem**
The file upload form submit automatically whenever the name of the selected file
changes.
If the user picks a file, and then navigates back the field is pre-filled
because the page is loaded from the browser’s back/forward cache.
This means that if they pick the same file again, the value of the upload field
hasn’t changed, and the form won’t be submitted.
**Solution**
The solution is to clear the form field[1] if the page is being loaded from the
back/forward cache. Then any time the user picks a file it represents and
actual change.
1. http://stackoverflow.com/questions/8861181/clear-all-fields-in-a-form-upon-going-back-with-browser-back-button
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.
