When a user creates a service we can take a pretty good guess at what
organisation they’re from.
For many organisations, especially local councils, GOV.UK branding is
not appropriate for their service. But right now every service:
- gets created with GOV.UK branding
- has to ask us to change it, even if they’ve already done so for other
services they run
This commit starts using the `domain` field on the email branding table
to lookup what email branding to assign to a service automatically,
where we’re sure there’s a sensible default.
When saving an email branding it’s possible we might not enter the
canonical domain for an organisation into the domain field. Because
we’re going to use the canonical domain to look up the brandings this
will cause a mismatch.
Rather than validate this and show an error, let’s just save the correct
thing instead. From the user’s perspective this means everything will
just work (ie a user with a given email address will automatically get
the right branding for their organisation).
We should make sure we’re not putting typos in the branding list. We can
validate what gets entered here against our known list of public-sector
domains.
Because we alias domains (eg `foo.gsi.gov.uk` to `foo.gov.uk`, or where
a local council has multiple domains) it could be hard to look up a
brand (which has one domain field).
Therefore we need a way of getting the canonical domain from a user’s
email address, which we can later use to look up their branding.
There’s something that feels a bit off about not being able to see the
name of the currently-selected branding when you land on the page.
Putting it at the top also means that you can easily switch back to it
if you change your mind.
If we’re going to be referring to email branding as part of the service
creation journey then we should make sure it doesn’t slow things down
too much by adding an extra API call. Caching things in Redis is a way
of avoiding unneeded API calls.
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.
Since GDPR came into effect it’s less clear about whether we can
contact teams for user research purposes.
If we make people opt-in (or not) we know we’re safe to contact them (or
not).
Since we mostly care about how services are using Notify for real (ie
live services) or services that are considering adopting it (ie those
who have contacted us with a question) it feels like the go-live process
is the most appropriate place to collect this consent.
Now that we’re a more mature platform we don’t care so much about the
load that one service might put on our platform.
We do care about intended volumes for two reasons:
- modelling the benefits that services get from using Notify
- managing stocks of envelopes (while our letter volumes are small
enough that they could be skewed by one new service)
Changing to the ‘how many per year’ question also has the benefit of
mapping directly to the data we store in the ‘beta partners’
spreadsheet.
Currently we keep track of live services in the ‘beta partners’
spreadsheet:
https://docs.google.com/spreadsheets/d/1JYhE5sJaOJUVMPPDenO2eKqElC75Rygxb1_2mpRKy98/edit#gid=503930061
Every time a service goes live we need to enter some data into the
spreadsheet about that service. Most of that data is copied from the
request to go live ticket.
This commit adds a line to the ticket with all the data needed by the
spreadsheet. It’s in the same order as in the spreadsheet, and it’s
tab-delimted so it should paste right on in there.
