The delete link was designed to be used with a button, where it needs
some padding to separate it from the button.
We now have a case where it’s being used without an accompanying button,
so we need a variation without that padding.
Users were having trouble finding the delete template link. It sort of
made sense having it on the edit page before we had the view template
page. But it doesn’t make sense now – having to choose to ‘edit’ the
template before you can delete is counterintuitive.
The single template page is where you go to choose an action to perform
on your template. Deleting is a good example of an action you can
perform on a template.
So this commit moves the delete link from the edit template page to the
view template page.
It also puts the confirm banner on same page as the delete link
The idea being that, in order to make a decision about whether to delete
the template, it’s useful to be able to see the template you’re
deleting. There’s no user need to edit the template before you delete
it.
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.
while PDFs work on paas, they only do that because it turns out the
python buildpack happens to have imagemagick preinstalled - if that
ever changes then it'd break. so move those to the template preview
service. This also means we can get rid of weazyprint and wand
dependencies
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.
