WTForms versions less than 3.0.0 have a security vulnerability where
arbitrary HTML can be inserted into the label of a form, allowing the
possibility of a cross-site scripting attack.
I don’t know if there’s anywhere we put user-generated content into form
labels but it’s possible we are vulnerable somewhere.
This require moving some imports because as of
https://github.com/wtforms/wtforms/pull/614/files
there is no longer a separate module for HTML 5 fields, they are now
considered core fields.
As of https://github.com/wtforms/wtforms/issues/445/files custom
implementations of `pre_validate` or `post_validate` must raise
`ValidationError` to trigger a validation message, where we were raising
`ValueError` this was no longer being caught.
As of https://github.com/wtforms/wtforms/pull/355/files `StringField`
returns `None` for empty data, not `''` but our `validate_email_address`
function only accepts strings.
We think that the API is returning incorrect data for this column.
It’s going to take a while to figure out what’s going on with the
queries in the API, so this pull request temporarily removes the column
so we’ve not giving people incorrect data.
We are starting to see lots of 100.0%s in the current table
and we think this looks suspiciously too good so think it is
beneficial to change it to be 2dp such that we get a few more
non 100.0% values.
This will put all the values in to having 2dp, however it will
also require the API to have a change to
https://github.com/alphagov/notifications-api/blob/master/app/performance_dashboard/rest.py#L81
where it is currently losing the granularity down to a single
decimal place (meaning that if we were really at 99.894% then that
would be shown on the page as 99.90% rather than 99.89%). However,
I don't think it is a blocker that we get that sorted before this
can be merged.
This means that the data in the report will match what’s on the page,
where the values are rounded to the nearest penny.
This uses the same string formatting to round the numbers which the
`big_number` component does, so it should round the numbers in the same
way.
It’s a pain having to remember to update both of them. Looks like `pip`
now supports a different syntax without the `egg` bit which means a git
dependency only needs the version number changing in one place.
This is so org level users can use this data easier for things
like determining spending per service.
We do not include sms fragments sent column and remove other sms columns
consistency.
Do not add sms fragments sent column for now until we agree on an
unambiguous name for it. The data in this column is sms billing units
multiplied by international sms weighing. My favourite for a clear
name would be 'text message credits used', but we need a naming
strategy for this.
The sentences in the key to the map have 2 forms:
1. the visual form, with an graphic pattern
alongside text saying what the pattern means
in the map
2. the semantic form, with text describing what
the pattern means and how big an area it covers
for this alert
This is achieved by making the graphic
non-semantic and having hidden words in the
sentence for each paragraph.
While the spaces between words are correct for
both forms of these sentences, we observed screen
readers speaking some groups of words as one when
they spoke the sentence. Most noticably, 'the
alert' was spoken as 'thealert'.
Swapping the class used to hide the visually
hidden words from ours to the GOVUK one seemed to
fix this. It's unclear why it does but the
`govuk-visually-hidden` class adds the following
styles to those in ours:
- width: 1px
- height: 1px
- white-space: nowrap
It also has `margin: 0` instead of `margin: -1px`.
At the moment, the icons in the key of the map
showing what each type of area drawn on the map
means change colour in high contrast mode. This
causes a mismatch between the areas on the map and
the key.
These changes remake the images in SVG to prevent
the colours changing in high contrast modes. They
also add a white background to the icons, to make
sure they match the areas they refer to in the
map.
Previously when trying to bring in
https://github.com/alphagov/notifications-utils/pull/889 we had trouble
because there were no wheels available for the version of Pip that we
were using. Now that we have upgraded to Python 3.9 we are using a
newer buildpack which should have the necessary wheels available.
This commit is just installing the package and nothing else, to give us
more confidence that we can merge
https://github.com/alphagov/notifications-utils/pull/915/files without
having to subsequently revert it.
The enhancedTextbox component has an element that
sits in front of the textbox and draws the
highlights over the text. This element has a 2px
border so it's dimensions match those of the
textbox. This border has a colour of 'transparent'
by default, to hide it from view but this is
overridden in high contrast modes to match the
text colour.
This adds some CSS targeting high contrast modes
which sets it to match the colour of the
background, making it invisible again.
The link-buttons we use in our pill component
have a blue background which shows the area they
occupy by default. In high contrast mode,
backgrounds are hidden so the link-button text
looks like it is floating because you can't see
the edge of their area.
These changes use the trick of adding a
transparent border. This is hidden by default but
displays in high contrast mode to show the edges
of the link-button. I've reduced the padding to
accommodate the extra space it takes up.
The mock up component, shown in all
current/past/rejected alert pages, doesn't show
fully in high contrast modes because it uses its
background colour to show its shape and
backgrounds are hidden in high contrast modes.
This uses a technique from design system which
adds a transparent border to these elements to
show their shapes. This works because borders of
any colour (even transparent) are rendered as the
foreground colour.
This makes it clearer that this model collection isn’t the organisations
for a user or a service or some other entity, like most model
collections are.
It will also lets us make a separate Organisations model, without the
name conflicting.
The model layer shouldn’t need to be concerned with sorting. For
services this means we can make a `SerialisedModelCollection` rather
than writing a manual loop.
Previously all our error messages had the class `error-message`.
Where we are using the components from GOV.UK Frontend they have the
class `govuk-error-message`.
This makes the code which jumps focus to the first error work in both
cases.
This commits adds test coverage for ther HTML in several of the forms
which had broken autofocus.
It means that if we make changes to the HTML which triggers autofocus in
the future it should be more obvious that something is depending on the
attributes being added/removed.
In 674c27a693 we updated the autofocus
Javascript to be compatible with GOV.UK Frontend textboxes, which have
the `data-module` attribute set on the `input` element, rather than on
a wrapper element.
However we still have some `<textarea>`s and `<input>`s which haven’t
moved to GOV.UK Frontend and therefore aren’t getting picked up by the
Javascript which is supposed to focus them.
This commit makes the Javascript work with both kinds of textbox, which
is needed until we move entirely to GOV.UK Frontend.
Previous the text input on the send one off SMS page was wrapped in
an element with a class of `form-group`. We overrode the spacing on this
element to make the links under the textbox move closer to the textbox,
so that visually they group together.
This was broken when we moved to GOV.UK frontend, which uses a class of
`govuk-form-group`. This commit changes the CSS to account for both
possibilities, because the send-a-one-off-letter page is still using a
textbox, not a text input, and textboxes haven’t moved to GOV.UK
Frontend yet.
This moves things out of the parametrization that didn't need to be
in there and also makes the test match the test below,
test_shows_delete_link_for_error_on_post_request_for_edit_email_reply_to_address,
more closely.
