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.
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
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.
> 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/
The accessibility audit raised the issue that screen reader users could
miss the table of data on the preview page, because it’s after the
submit/back buttons.
> The back button is before the table of error messages - a screen
> reader user might read the initial error summary then get to the back
> button and not realise the error detail are later in the sequence.
> The send and back buttons are before the table of field values - a
> screen reader user might read the template details ror summary then
> get to the buttons and not realise the field details are later in the
> sequence.
This commit add a skip link to navigate the users directly to the table,
which:
- allows them to skip past a lot of content which they might already
have read
- makes them aware that the table exists
It’s added:
– as the first thing after the `<h1>` when there are no errors with the
file
- as the last thing in the error summary when there are errors with the
file
The link is hidden from those interacting with the site visually.
The previous, weekly activity breakdown was what we reckoned might be
useful. But now that we have people using the platform it feels like
aggregating a service’s usage by month is:
- matches the timeframe users report on within their organisation
- is consistent with the usage page
And like the usage page this commit also limits the page to only show
one financial year’s worth of data at once (rather than data for all
time).
This commit also makes some changes to the jobs view code so that our
aggregation of failure states is consistent between the dashboard pages
and the jobs pages.
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
We have a bunch of different styles of handling when function
definitions span multiple lines, which they almost always do with tests.
Here’s why an argument per line, single indent is best:
- cleaner diffs when you change the name of a method (one line change
instead of multiple lines)
- works better on narrow screens, eg Github’s diff view, or with two
terminals side by side on a laptop screen
- works with any editor’s indenting shortcuts, no need for an IDE
Also, trailing comma in the list of arguments is good because adding a
new argument to a method becomes a one line, not two line diff.
(I suspect that) because Python dictionaries are not ordered, you can’t
rely on the order of query parameters in a URL to match the arguments
passed to `url_for`. This means the tests can intermittently fail.
This does some hacky workaround stuff to still have reasonable test, but
one that will pass whatever the order of the query parameters is.
`severe` can mean one of three things:
- `yes` – user has told us this is an emergency
- `no` – user has told us this isn’t an emergency
- Anything else – user hasn’t been asked the question or has
hacked/mangled the URL
This commit adds some stricter sanitisation of the `severe` query
parameter and does so up front, rather than spreading it across multiple
functions.
`replace` doesn’t convert a time from one timezone to another. It just
changes the label that says what timezone a time is in 😬
`.localize` is how we handle these kind of issues in the API (see
d0b467b2fb/app/utils.py (L42-L44) )
So this commit changes the calculation to use `.localize`, and makes the
tests timezone aware to check we’re doing this right.
Using and/or over any/all has a couple of advantages:
- it's a bit quicker
- it won't evaluate the second half at all if the first half fails – if
it is in business hours, and convert_to_boolean would raise, with your
use of all we'd throw a 500, whereas if we had or, business_hours
would trip and we'd skip over the second half without worrying about
exceptions
any and all are designed for use with variable length args eg
`any(x for x in thing())`
previously it was attempting to do so from outside of a session
transaction, so failing. This still only happens when you've called
`login` with a mocker and service json blob, which is probably worth
reconsidering in the future, but for now, updated logged_in_client to
use the extra login args
If you report a problem we want to be able to get back to you to find
out more information, or to update you on the status of a fix. So it
shouldn’t be possible to report a problem without providing an email
address.
This commit makes `email_address` a required field when `ticket_type` is
problem.
This requires a bit of fiddling with the tests which weren’t expecting
to have to provide an email address. So the tests now either:
- pass an email address
- check for an error when they don’t pass an email address
This is a real edge case, but it seems worth handling.
How you’d get to this case:
- it’s 5:29pm and you start to describe the problem you’re having
- it’s 5:31pm and you click ‘submit’
- you’re redirected to the triage page because we’re now out of hours
- you click ‘this is a serious problem’
What would be bad thing to happen:
- you’re back on the message page and all the stuff you’ve written is
gone
What would be a good thing to happen:
- we save the message in a session so that you can check it again before
sending it
Generally I prefer confirmation pages to the flash message thing
(they’re harder to miss). So this commit adds one.
It also adds some logic to this page, so that, depending what the user
has told us about the thing they’ve submitted, we can tell them how
quickly to expect a response.
TL;DR, as much as possible we should work out how to prioritise tickets
and not put that burden on the user. However, there are some cases where
we can’t.
In business hours all tickets are high priority, ie we will at least
acknowledge them within 30 mins.
If we are not in business hours then we need to know if a ticket is
serious enough to get someone out of bed. Only the user can tell us
this, but we can give them some examples to help them decide.
In addition, out-of-hours tickets are only a priority if the user has
live services. Normally we can determine this and do the
priority-setting in the background.
If they can’t log in then we can’t determine what services they have. So
in this case they will need to use the emergency email address, which
only users with live services will have.
The logic for this gets fairly complex. It might be to easier to
understand what’s going on by walking through the test cases, which are
a bit more declarative.
N.B. Deskpro’s ‘urgency’ is descending, eg 10 is the most urgent and 1
is the least.
If a user is logged in then we already know their name and email
address. So there’s no need for them to fill them again on the support
form.
One concern we might have about this is the user not realising we’re
doing this, and the feedback form looking like a bit of a black hole.
So we’re replaying their email address on this page to reassure them
that:
- we know who they are
- and that they’ll get a reply
The kind of communications we’re getting at the moment can broadly be
broken down into:
- problems
- questions and feedback
We will need to triage problems differently, because they could
potentially be urgent/severe/emergency/P1/whatever language we use.
Questions or feedback will never be P1.
Two reasons for making the user categorise their tickets themselves:
- Outside of hours we can’t get someone out of bed in order to decide if
a ticket is a problem or just feedback
- We can tailor the subsequent pages to whether it’s a problem or
feedback (eg showing a link to the status page if the user is having
a problem)
This commit let’s users make the choice with a pair of radio buttons.
It also cleans up a bunch of the tests and parameterizes them so we’re
testing the flow for both ticket types.
Our support process is about to get more fully fledged so we’ll need
an index page to route people properly.
We reckon that users will also want to know what the support process is,
so let’s explain it on this page.
