We’ve had a couple of instances where teams have sent the wrong template
to a …number of users.
Sometimes templates can be very similar and only have slight variations
to tailor them to a specific subset of users. So identifying the right
template by sight can be difficult.
We know that teams do give their templates meaningful names, and use
these names in other tools (spreadsheets etc) to refer to the templates.
So putting the name of the template on the page where you’re about to
send all the messages seems like it’s gives people an easier way of
double checking that they’re doing the right thing.
I umm’d and ahh’d over the wording a bit, and think ‘Preview of…’ reads
the best. It looks a bit weird because most template names are Title
Case. I think it’s better than some ambiguous punctuation (eg ‘Preview:
Template name’ or ‘Template name – preview’).
Some examples of real template names:
- Preview of Example text message templates
- Preview of Online LPA payment application reminder
- Preview of Create user account
- Preview of Split journey - Unknown credentials
- Preview of Public user: application without supporting documents
- Preview of Renewal Survey – February
- Preview of CEX New adult
- Preview of Applications are closing tomorrow
- Preview of Your application result - if successful
> Scottish Enterprise is Scotland's main economic development agency
> and a non-departmental public body of the Scottish Government.
– https://www.scottish-enterprise.com/about-us
For some reason their email domain is `scotent.co.uk` (but it redirects
to www.scottish-enterprise.com on the web for the some reason
¯\_(ツ)_/¯)
The user has 10 tries at the password, after which the account is locked.
The same is true for the verify code, the user will have 10 tries before the user account is locked.
> When the CSV is missing the header row, we get an error and the user
> will see "Sorry, we are experiencing technical difficulties..."
>
> We should return a better error message for the user.
– https://www.pivotaltracker.com/story/show/140668615
This was caused by an attempt to access the `first_recipient` variable
before it was assigned. It would only be assigned when there was at
least one row in the file.
Fixing this means doing two things:
- defaulting `first_recipient` to be `None` before looking in the file
- adding an error message for when we can’t extract any rows out of the
file (which is more nuanced than the file just being completely empty)
(There’s a nasty `sort` in the Jinja template because when there are no
rows in the file the order of the required column headers is not
deterministic.)
specifically, the 2FA page when you first create an account is different to the login 2FA page
and also the 2FA page when you change your phone number is different as well
when a user enters their 2FA code, the API will store a random UUID
against them in the database - this code is then stored on the cookie
on the front end.
At the beginning of each authenticated request, we do the following
steps:
* Retrieve the user's cookie, and get the user_id from it
* Request that user's details from the database
* populate current_user with the DB model
* run the login_required decorator, which calls
current_user.is_authenticated
is_authenticated now also checks that the database model matches the
cookie for session_id. The potential states and meanings are as follows:
database | cookie | meaning
----------+--------+---------
None | None | New user, or system just been deployed.
| | Redirect to start page.
----------+--------+---------
'abc' | None | New browser (or cleared cookies). Redirect to
| | start page.
----------+--------+---------
None | 'abc' | Invalid state (cookie is set from user obj, so
| | would only happen if DB is cleared)
----------+--------+---------
'abc' | 'abc' | Same browser. Business as usual
----------+--------+---------
'abc' | 'def' | Different browser in cookie - db has been changed
| | since then. Redirect to start
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
