Pytest moved its cache from `./.cache` (which is in our `.gitignore`) to
`./.pytest_cache` (which isn’t).
It’s annoying having to be careful not to commit it all the time, so
this commit makes it ignored.
See https://github.com/pytest-dev/pytest/issues/3286 for more context.
To correspond with us dropping this column from the database.
Remove the attribute from the model gives us more confidence that it’s
not being used (because it will raise exceptions in any tests that refer
to it).
We sometimes have to do this over support tickets as part of the go-live
process; now we’re directing people to add a sender (as part of the task
list) we can explain what it is in context.
Tests the new code that gets the brand type from
the email_branding model. Includes checks for a
service without the email_branding field set.
It also amends the test for a POST from that page,
removing mocking of the email_branding client.
This test runs against the default service which
has its email_branding field set to None so no
call is made to the client. It's testing the
brand_type values selected so doesn't need the
service to have an email_branding already set.
This is just the pricing page, we'll sort the pricing table etc separately...
W're removing non-crown pricing as we won't be charged differently any more. But we will retain the concept of non-crown as we may change differently ourselves in the future.
Setting the branding_style to 'None' causes the
API to remove the email_branding field from a
service model. The branding request page
controller was depending on that value being
to present get the brand type.
The email preview page (used in an iframe on
various pages) wasn't able to recognise a
branding_style of 'None', causing a blank page to
render.
Removes any checks for branding_type from tests
for set_email_branding page.
Updates tests for email preview page (usually
iframed) so non-default brand_type is got from the
email_branding model instead of a GET param.
We often check that a service has an appropriate text message sender as
a condition of them going live. We don’t mention this anywhere.
The services for whom GOVUK is definitely not an appropriate sender are
those in local government. As we have more of these teams starting to
use Notify, we should streamline the process by making this check
automated.
This commit adds that check, for teams who:
- have text message templates
- have self-declared as NHS or local government
We’ve found a significant property of users (about 25%) who request to
go live aren’t completing all the items on the checklist.
In 1 of 6 (17%) of the usability testing sessions we did on this process
we saw someone skip straight past the checklist page because of big
green button syndrome. While 1 in 6 people would normally be a small
number[1] in the context of a usability testing session, it’s enough to
cause a big workload for our team (assuming it is the sole cause of
people not completing the items on the checklist).
The initial reason for using the tick cross pattern for the checklist
was:
- it was coherent with the rest of Notify
- the task list pattern didn’t have a way of showing that something
still needed doing – it put more visual emphasis on the things
the user had already done
There’s been some interesting discussion on the GOV.UK Design System
backlog about users failing to complete items in the task list. A few
people have tried different patterns for communicating that items in the
task list still need ‘completing’.
So this commit:
- adds a task list pattern
- uses the task list pattern for the request to go live checklist
The task list is adapted from the one in the design system in that:
- the ‘completed’ label has a black, not blue background (because Notify
often uses blocks of blue to indicate something that’s clickable)
- it adds an explicit ‘not complete’ label which is visually not
filled in (sort of how ticked/unticket radio buttons work)
1. With the caveat that looking only at task completion, or quantifying
qualitative not good practices and the intention here is to show that
the numbers are close enough to say that they could be symptomatic of
the same problem. Leisa Reichelt’s Mind the Product talk is good on
this https://vimeo.com/284015765
