bump utils to 13.8.0
we still save the content as the user intended, and they'll still see
that content in the text field if they go to edit the template, but
the SMS previews will appear as they will on a user's phone
Use `it`/`they` depending on how many different characters you've used
Also don't wrap the message with quotes, as it looks confusing and
potentialy implies that you can't use apostrophes
mostly making sure that the correct user is set up. some minor changes,
such as giving the platform_admin service permissions (so that we can
test that platform admins can send letters)
mock_has_permissions blindly returns True - this is useful for the
decorators on most endpoints checking if the user has permission to
access endpoints about the provided service, but is not useful when
it returns true to such checks as "if user is platform admin, show
secret stuff", despite the logged in user being
"active_user_with_permissions" rather than a platform admin.
So remove this, and add "logged_in_platform_admin_client" for when we
want to explicitly check platform admin functionality.
This has the advantage of the actual permissions code being checked
in tests, so the test environment is more consistent with the real
world.
Several tests will have to change now though - active_user_with_perms
has permissions for service_one, so most tests should now call
client.get(url_for(..., service_id=service_one['id']) or they'll 403
> Users that allow their session to expire, or access a bookmarked link
> are told they need to "Sign in to access this page" - we should
> explain that it's because they've been away a while, so that they
> understand why they're being asked to log in again.
– https://www.pivotaltracker.com/story/show/140016919
The message we were showing before (Please log in to access this page is
the default message from Flask Login).
In order to stop this flash message from appearing, we need to override
the default handler for when a user is unauthorised. We’re overriding it
with the same behaviour, minus the flash message.
If you navigate deliberately to the sign in page it’s unchanged.
Content is Sheryll-approved.
When your CSV file is missing the recipient column (eg ‘phone number’
or ‘email address’) we give you a helpful error message telling you that
this is the case.
When we changed the recipient column to be columns, plural, we didn’t
update the code that generated the error message. So you would get
errors that looked this like this:
> Your file needs to have a column called ‘’
This commit fixes the error message.
The bars were sitting in a table cell with some right padding, so they
never extended all the way to the right. Making it right-aligned removes
this padding, then setting the text to left aligned keeps things looking
the same.
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.
The HTML validator picks up this error in our code:
> Self-closing syntax (/>) used on a non-void HTML element. Ignoring
> the slash and treating as a start tag.
We do our own server-side validation of things like email address. We
don’t want the browser also trying to do it based on the input type of a
form field. It’s bad because the browser validation message comes up as
a nasty little tooltip under the field.
The heading structure of most pages is incorrect (`<h2>` followed by
`<h1>`). The `<h1>` indicates the main purpose of the page, the service
name (currently the first `<h2>`) doesn't need to be a heading.
In pages specific to a service (e.g. dashboard and sub pages) the title
needs to distinguish which service it applies to. This is mainly to give
context to screen reader users who could be managing multiple services.
Implementing this uses template inheritance:
`page_title` includes `per_page_title` includes `service_page_title`
‘GOV.UK Notify’ is inserted into every page title.
Pages that set `service_page_title` get the service name inserted too.
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.
> 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.
This commit adds the dedicate error summary at the top of the page,
following the GOV.UK Elements style from:
http://govuk-elements.herokuapp.com/errors/
