service contact blocks contain new lines - and jinja2 normally ignores
newlines (as in it keeps them as new lines) - but we need to turn them
into `<br>` tags so that we can show the formatting that the user has
added. We were previously just doing `{{ block | nl2br | safe }}`. nl2br
turns the new lines into `<br>` tags, and then `safe` tells jinja that
it doesn't need to escape the html.
this causes issues if the user adds `<script>alert(1)</script>` to their
contact block (or some other evil xss hack), where that will get let
through due to the safe flag
To solve this, use `Markup(html='escape')` to sanitise any html, and
then convert new lines to <br>.
bump utils
another xss
Includes:
- new content
- added option to turn analytics on/off
- non-js version for the on/off switch
- a banner to confirm user's choice was saved,
shown when they click the save button
- the cookie banner that appears on all other
pages removed from this page
This way we have a URL we can give people that always points to the
latest version of the spec.
And it makes our code more Flask-idiomatic to be using `url_for` to be
generating a URL, rather than passing around a constant.
We show letter validation errors in two places:
1. In response to a user uploading a PDF
Here we use the error banner pattern because the problem is as a
direct consequence of a user’s action, and is blocking them from
continuing.
2. Once a PDF provided through the API has been validated
We use a less prominent pattern of red text with no border because
the message is reporting on something that’s already happened, and
which wasn’t a direct consequence of the user clicking something
Because the context and patterns used are different we need slightly
different content in each of these situations. Previously we tried to
reuse the same content to make the code cleaner and less repetitive. But
ultimately a clear interface trumps clear code.
Update list of organisations that can use Notify to remove 'housing associations' and rephrase 'companies owned by local or central government that deliver services on their behalf'.
By moving it from the view we reduce the complexity of the methods in
the view layer, so it’s easier to see what they do.
This also renames the variable `finished` to the property
`processing_finished` to disambiguate from the `job_status` field in the
JSON, which can also have a value of `finished`.
This follows the pattern of what we’ve done with services, users and
events.
It gives us a way of neatly instantiating a model for each item in the
list we get back from the API and reduces the complexity of the view
layer code.
Now is a good time to do this because we’re going to be making a bunch
of changes to the jobs pages, and those changes will be easier to code
and understand with a sensible model behind them.
This follows the pattern of what we’ve done with services, users and
events.
It gives us a better interface to the data we get back from the API than
dealing with the raw JSON directly.
Now is a good time to do this because we’re going to be making a bunch
of changes to the jobs pages, and those changes will be easier to code
and understand with a sesnsible model behind them.
Now persisting the address to the "to" field of the Notification, after the notification has been validated.
If the letter is pending validation, then "Checking..." will appear as the identifier for the letter.
If the letter has passed validation, then the first line of the address (now persisted in the "to" field) will be displayed, with the client reference underneath.
If the letter has failed validation the "Provided as PDF" will show be displayed, which is now the initial value of the "to" field.
Before deploying a change to template-preview to return a validation error for letters that are missing the address block, we need to add the new erorr message to admin.
Some content changes have been made to other messages.
The format of the message has changed.
Includes:
- new content
- added option to turn analytics on/off
- non-js version for the on/off switch
- a banner to confirm user's choice was saved,
shown when they click the save button
- the cookie banner that appears on all other
pages removed from this page
Precompiled letters sent via the API don’t have:
- a template
- a filename
Which means in the list of returned letters we just show ‘None’. This
commit changes this to ‘Provided as PDF’, which is how we talk about
precompiled letters elsewhere (for example in the template statistics on
the dashboard).
Our table rows take up 65px vertical space.
We also have things that look like rows that say:
- there are no rows
- there are more rows than can be shown on screen
This commit makes them appear the same height.
It’s useful to get some kind of preview of the report before you
download it.
And if there’s only a few letters in there then you might not even need
to download it at all.
For teams with lots of letters we don’t want the page to load too slowly
so let’s cap the number of displayed items to 50, same as previewing
a spreadsheet.
This page displays a list of available reports, a report is a set of returned lettters that have been reported on the same day.
Each line of the page is a link that can download the report.
I'm not sure the format of the csv is right. The data might be confusing especially if the service has a mix of precompiled templates and jobs.
Units tests are still to come.
