This is another problem with sanitising HTML, this with with it getting
encoded where it shouldn’t be. The result was, when editing a template,
the API getting sent an encoded rather than raw version of the subject
(for letters and emails).
The reason this happened is because BeautifulSoup behaves in an
unexpected way.
When accessing the `value` attribute of an `input` BeautifulSoup returns
an unencoded version of the contents. In other words it returns what the
user would see in the page, not what is in the raw HTML of the page.
This meant that we were trying too hard to see an `&` instead of a
`&` in our tests[1]. So things were actually working fine before adding
the call to `escape_html`[2], but from the output of the tests it didn’t
look like HTML was getting escaped.
So this commit fixes the bug by removing the call to `escape_html` and
adding a test that looks at the raw HTML, to complement the existing
test which looks at just the `value` attribute.
1. Relevant test added here: https://github.com/alphagov/notifications-admin/pull/1178/files#diff-f2eb304b93cc383727c0ab7fc8fbd464R289
2. Call added here: https://github.com/alphagov/notifications-admin/pull/1178/files#diff-f0af582449ebf426f27f37e38f310057R252
Problems:
- WTForms expects the value of checkboxes to always be `y` (they don’t
work like radio buttons, which is where I copied this code for)
- WTForms `BooleanField`s don’t have a checked attribute, they set their
data attibute to `True` or `False`
Not sure what about the new radios is causing this, but they no longer
expand the size of the container, causing an overlap.
The fixed height was originally for performance reasons, but removing
it doesn’t seem to cause the page to jump around on load, so I think
it’s OK.
GOV.UK Elements changed tables to be a larger font size here:
https://github.com/alphagov/govuk_elements/pull/185
This is good in principle (and a lot of our tables are 19px already).
However, the ones that aren’t are still 16px because there’s a lot of
info to fit on the page (eg when previewing someone’s CSV file).
Not sure why we were doing this. But as part of the Elements upgrade
our back buttons got bigger (because they weren’t constrained by the
line in our `app.scss`) but any green submit buttons stayed smaller in
height, so didn’t line up.
This commit removes the override, so all buttons have the size that
Elements intended.
The Elements CSS was making the `label` and `input` of disabled radio
buttons `opacity: 0.5`. This was resulting in text that was:
- too pale, especially where we were nesting 16px ‘hint’ text inside the
label
- waaaay too pale when inside a link inside the label
This commit overrides elements to dim the disabled radio button by
making it’s text colour grey, rather than making the whole thing
semi-transparent.
The visual appearance of radio and checkbox form inputs changed in
GOV.UK Elements here:
https://github.com/alphagov/govuk_elements/pull/296
This was subsequently reimplemented with different markup and no
Javascript here:
https://github.com/alphagov/govuk_elements/pull/406
This has meant making the following changes to our app:
- changing the markup in our radio/checkbox macros to match the example
markup given by GOV.UK Elements
- removing the previous Javascript file because it’s no longer needed to
make the radios appear visual selected
- making the buttons on the scheduled job picker look like links,
because the grey button style looked weird with the new radio buttons
- SMS message preview gets slightly wider so it lines up with a 4/8
column
- Edit email box gets wider to match more closely the width of the
previewed and delivered emails
Not sure how these got out of line (maybe when we brought the date into
the left-hand text area). But this commit updates the percentages to
match the comments.
This is so it’s clear from the position of the link which part of the
letter you’re editing.
The textbox we use for editing letters is the same size as that for
email and text messages.
This is problematic because:
- it feels quite cramped – letters will often be longer than emails or
text messages
- it has a narrower line length than the printed letters (which is a
constant, unlike for emails and text messages)
The printed letters have a line length of 137.5mm and a font size of
12.5pt.
137.5mm = 5.41 inches = 389.7pt line length
389.7pt/12.5pt = 31.8em
So we could make the box 31.8em wide, but then it wouldn’t align to our
grid.
Our grid splits the page into quarters initially because this is how
wide the navigation is. So this means that we can use grid units of
1/multiples of four, eg 1/4, 1/8, 1/12, 1/16, etc. But the smaller the
denominator, the less effective the grid will be – it gets closer to no
grid at all.
After having a play around, 5/8 of the page looks closest to 31.8em.
Since the main column of the page is 3/4, we set a column of 5/6 width
inside that, which equals 5/8 of the total page.
We’ve seen in letters usability testing that people get stuck in a
“no-man’s land” when trying to go back from the _Send yourself a test_
page.
This was broken for two reasons:
- we hadn’t considered that a letter template without placeholder still
requires you to fill in
- we’ve changed subsequently made the _view template_ page the place
where you do your actions, rather than the (old) page with all the
templates shown
So this commit fixes it so that the back link always take you back to
the page you were previously on, and adds some more test cases so we
have all the scenarios accounted for.
The `format_datetime_relative` filter is only used by the scheduling
stuff, which only deals with dates in the future.
When used on dates in the past (more than 1 day ago) it gets confused
and defaults to ‘tomorrow’.
The `format_delta` method does a similar thing, but works for past and
future dates.
Users can still click through to the next page to see the exact date and
time of the edits.
Address line 3 is optional. Currently the only way we have of indicating
to users what is/isn’t optional is by using the example. Which probably
isn’t ideal, but should at least be correct.
