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.
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`
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).
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
Brings in:
- [ ] https://github.com/alphagov/notifications-utils/pull/128
This means that `RecipientCSV` will sometimes return the value of a cell
in a spreadsheet as a `list`, not a `string`. So we need to handle that,
rather than putting a Python representation (`['one', 'two', 'three']`)
on the page.
This commit handles it by putting a bulleted list on the page instead.
This breaks our model of showing the spreadsheet as it appears in Excel
or whatever, because we’re showing the aggregation of the columns into a
list. However:
- this is the easier thing to do for now
- it might actually be more usable because it keeps the table narrower
Removed as part of refactoring the code to generate the graphs of
template usage on the dashboard:
4a226a7a29 (diff-cf78cb5c29a2d3c4d45b61d8617824b7L29)
Didn’t realise that they were used by the functional tests.
This commit puts them back while keeping the code reuse.
This was used on the old product page to do the graphic of three phones
showing three different messages. We don’t have this any more, so this
‘component’ is unused.
Also removes some unused imports which were a hangover from previous
versions of the product page.
no actual template functionality yet - just the ability for services
that have letters enabled to edit a 10 line block that will go on the
top right hand side of their letters with contact information
There’s a good reason for having the ` ` – it stops GOV.UK Notify
being split across two lines (which could happen on a smaller viewport,
eg mobile). Gotta protect the brand.
Not good for the brand for it to be showing up in the page though 😬
This got broken as part of 3f41090a94
The label for a form should never have user-submitted content in it, so
using `safe` is fine.
In HTML you generally can’t nest an inline level element inside a block
level one, if you want your HTML to validate.
There were a couple of places where we were using a `<span>` as a
containing element:
- inside every table cell (think we inherited this from Digital
Marketplace)
- in the ‘pill’ navigation component for the selected tab
This meant that when we put components like big number inside these,
the resulting HTML was invalid, because big number is built with a bunch
of `<div>`s, which are block level.
This commit removes the use of a `<span>` tag in these places, and
replaces it with a `<div>`. Nesting block level elements in fine in
HTML.
Currently it’s not possible for a screen reader user to know which
financial year they’re looking at. From the accessibility report:
> The financial year links are contained in a navigation region -
> tabbing or arrowing through only reads out the links, not the main
> information of "2016 to 2017 financial year" - that information is
> vital for understanding the page content.
This problem also applies to other pages which use the `pill` component,
which is effectively tabbed navigation (that reloads the page rather
than showing or hiding content on the page).
There are specific ARIA attributes that can be used to mark up a
navigation as being tabbed. This commit:
- adds those attributes
- makes the selected ‘tab’ visible to screenreaders and keyboard
focusable
- adds a visual focus indicator to the selected tab
- adds `id`s to the parts of the page that are controlled by the tabs so
that they are labelled as such
This also means changing the pill component from being a `<nav>` to a
`<ul>` because `tablist` is not a valid `role` for a `nav`.
Mostly follows the example here:
http://accessibility.athena-ict.com/aria/examples/tabpanel2.shtml
It’s invalid HTML to have multiple labels nested within each other. This
was happening by accident because WTForms tries to be clever – when you
put `{{ field.label }}` in a template it prints a `<label>` tag for you,
not just the text of the label. But we put our own `<label>` tags in the
HTML to have more control of them.
This commit stops WTForms being so clever.
This is mainly for the ‘check’ page where we show users the contents of
their spreadsheet.
> The structure of the table means that the first cell is treated as a
> column header, so moving through columns in row 2 for example
> associates the data 2 with 1 (column header) - this has no logical
> meaning
> If both sections of the page have errors and the page is submitted,
> focus moves to the mobile numbers section so screen reader users may
> not be aware of preceding errors - focus should move to a dedicated
> error summary at the top of the page.
Right now we use Javascript to focus the first error on a page (if any
errors are found). This commit adds more JS to then focus the error
summary, if there is one on the page. So this is where the focus will
rest.
It also makes some modifications to the ‘dangerous’ banner to make it
focusable, and to visually indicate that it is focused.
Currently screen reader users would click the ‘Copy API key’ button but
not get any feedback. This commit adds an ARIA attribute which tells the
screenreader to announce any changes in to the content of the element
(eg when it changes from showing the API to showing the text ‘API key
copied to clipboard’).
Right now we tell people that the usage page is for the current
financial year. This is a lie – it’s for all time.
So this commit calls through to the API to get the stats for (by
default) the current financial year.
We already do this for the monthly breakdown, this just does the same
thing for the yearly totals.
It also adds navigation to show the data for other financial years:
- previous so you can go back and see your usage and verify that the
bill you’re about to pay is correct
- next so that you can check what your SMS allowance is going to be
before you actually get into it
Let users create/edit/delete letter templates.
Let them upload a CSV file or send a test against a letter template.
Big assumption at the moment is that addresses only have one line, and
therefore one column in the CSV file.
This is trying to resolve these confusions:
- that you’re in trial mode, which means you can’t have a live key yet (
or you can but it wont work, which is what we used to have)
- what does simulate mean
The create key page is the right place to resolve these confusions
because it’s where users are actively reading.
This commit also removes the trial mode banner from API integration
page because this where users _aren’t_ actively reading. A whole bunch
of users weren’t seeing this banner at all.
The implementation of the disabled API key options is kinda clunky
because WTForms doesn’t have a native way of doing this.
¯\_(ツ)_/¯
The options for scheduling a job by time should be grouped by day,
because a long list of 96 options is not very usable.
On the server side, this commit generates label for the next 4 days in
a friendly format (ie today/tomorrow/Sunday/Monday)
The Javascript component for choosing a time was built in a kind of
old-school jQuery way, where it manipulated the elements on the page.
The complexity of introducing groups of options was just too much for
this pattern, because it involves storing a lot of state in the DOM.
This commit completely rewrites the JS to:
- read the initial options and groups from the HTML and store them
in the object
- use Hogan to completely re-render the UI from a series of Mustache
templates, each of which represents a state of the UI and takes the
inital options and groups
- filter the choices to show when the today/tomorrow/… buttons are
clicked
The browser tries to be helpful by autofilling email addresses and
phone numbers. But it gets confused and tries to fill all the fields
with the same email address or phone number. This looks broken.
This commit disables autocomplete for these form fields.
Services who are in alpha or building prototypes need a way of sending
to any email address or phone number without having to sign the MOU.
This commit adds a page where they can whitelist up to 5 email addresses
and 5 phone numbers.
It uses the ‘list entry’ UI pattern from the Digital Marketplace
frontend toolkit [1] [2] [3].
I had to do some modification:
- of the Javascript, to make it work with the GOV.UK Module pattern
- of the template to make it work with WTForms
- of the content security policy, because the list entry pattern uses
Hogan[1], which needs to use `eval()` (this should be fine if we’re
only allowing it for scripts that we serve)
- of our SASS lint config, to allow browser-targeting mixins to come
after normal rules (so that they can override them)
This commit also adds a new form class to validate and populate the two
whitelists. The validation is fairly rudimentary at the moment, and
doesn’t highlight which item in the list has the error, but it’s
probably good enough.
The list can only be updated all-at-once, this is how it’s possible to
remove items from the list without having to make multiple `POST`
requests.
1. 434ad30791/toolkit/templates/forms/list-entry.html
2. 434ad30791/toolkit/scss/forms/_list-entry.scss
3. 434ad30791/toolkit/javascripts/list-entry.js
4. http://twitter.github.io/hogan.js/
On the dashboard:
- adds a new ‘in the next 24 hours’ section to the dashboard which lists
upcoming jobs
- tweaks some spacing on the dashboard so that it doesn’t look like too
much of a mess
- don’t show scheduled jobs in the table of normal jobs
On the jobs page:
- don’t show scheduled jobs
Users need to pick a time in the next 24hrs, or send a file immediately.
Rationale for this is a bit lost in time-before-holiday, but generally:
‘Now’ and ‘later’ as the inital choices makes it really clear what
this feature is about conceptually.
The choice of times is absolute, eg ‘1pm’ not ‘in 3 hours’
There’s no point in collapsing […] the email on the single template
page because it’s the only thing on the page.
Users will probably be going back and forth quite a bit to edit their
template and see the changes; they shouldn’t have to expanded it evey
time to check they’ve got the heading syntax right, for example.
The team page was a bit of a mess:
- invited and active tables didn’t line up
- lots of things were wrapping onto two lines
- the empty fields for when a user didn’t have permissions looked broken
This commit splits each row of the table (not actually a table any more)
onto two lines. First line has the user’s info, second has their
permissions and any associated actions.
This commit extends the `ajax_block` component to take a `dict` of
partials, from which it can select the partial matching its `key`
argument and print its HTML to the page.
This means that the same markup is only rendered in one place, rather
than in two (individually in the JSON endpoint and as `include`s in the
parent template).
This is less repetitive than typing out the HTML with all its attributes
every time.
It also lets us wrap up the idea of ‘finished’ as a parameter, so the
AJAX code will only be initiated when it’s needed, eg if a job is still
processing.
