make sure everything is using the `nl2br` formatter that properly wraps
it in markdown to keep everything sanitised nicely. Also write a couple
of tests
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
`recently_created` says it would just be looking at the `created_at`
field to see if it's been created recently. Technically this method
isn't doing that, whilst its behaviour would be similar, it's actually
different and maybe therefore a bit misleading.
It looks like a link so its semantics should
identify it as one.
This can effect users of speech recognition
software, in scenarios where they instruct it to
click an element which looks like one thing but
the software can only identify as something else.
Visual users get the context from the proximity to
the h2 but we need to provide this for others.
I've tried using `aria-describedby` to link them
to the h2 but this ends up making the h2 text the
button's description in the accessibility tree. In
Voiceover this means you only get that information
as extra context, announced a while after the
label if the VO cursor stays on the button.
We want all the information in the accessible
label so chose this approach instead.
Paired with @aliuk2012 on the implementation and
with a view to making the component generic enough
to be used on digital marketplace apps as well.
These changes came from that session.
They include:
- removal of an unused `data-accept-cookies`
attribute
- removal of `govuk-!-padding-top-4` class and
moving of associated styles into component CSS
- swapping out the `aria-label` on the parent
element for an `aria-describedby` linked to the
h2 to have one thing labelling the banner region
- removal of unused CSS and any already provided
by the govuk-button class
- inclusion of @import's for styles attached to
govuk-body and govuk-button classes
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
Removes the following cookies:
- seen_cookie_message (flags if banner was already
shown)
- _gid (Google Analytics cookie)
- _ga (Google Analytics cookie)
These were set by default before so potentially
still around for some users.
The code for this now exists as a static method on
the cookieMessage module and is called when the JS
loads for the first time.
Copies HTML and Sass from GOV.UK Pubishing
components cookie-banner with changes to content
and functionality to better suit Notify.
Changes are:
- adds a 'reject' button which the GOV.UK
code doesn't have
- adds Sass from the GOV.UK Frontend button
component which the GOV.UK version used so
is included here
- removed click tracking from cookie banner
Notifications won’t exist for a job if:
- it’s just started
- it started a long time ago (older than the retention period)
We have a bug where:
1. Job starts processing, puts notifications on queue
2. Job finishes processing, sets status to `finished`
3. First notification gets picked up off the queue and put in the
database
In between 2. and 3. it’s possible for a job to be finished, but also to
have no notifications. We’re saying this is because the notifications
have been deleted, whereas really it’s because they haven’t been created
yet.
This commit fixes that bug by introducing the concept of recency for
jobs.
‘Recent’ is defined as 1 day, which is:
- a lot longer than it takes to create any notifications
- a bit shorter than anyone’s retention time
N.B. `processing_started` is defined here:
879ba1d5f0/app/models.py (L1194)
It can be `None` for scheduled jobs that haven’t started yet.
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.
