Got some advice from the content community:
> I don't think we have a style on this - it doesn't really come up on
> GOV.UK mainstream.
>
> In your example, I'd go with something like 'less than £250 before
> VAT' or 'less than £250 (not including VAT)' to make it as clear as
> possible. Would that work?
I’ve gone with ’less than £250 (before VAT)’. I noticed that elsewhere
we’ve said ‘Each message costs 1.58 pence (plus VAT)’ so that feels
fairly consistent.
Pages within a service use a 2/8, 5/8, 1/8 grid.
The content pages use a 1/4, 3/4 grid, for consistency with the product
page template.
But I feel like the internal consistency is more important, and it feels
weird for the main content column to jump about.
So that you don’t have to use the footer navigation to switch between
these related pages. Matches the template we use for organising
features-related content.
When a user deletes their service we take them to the ‘Choose service’
page. Like other non-service-specific pages this has a link to the last
service you were looking at. But in this specific case the last service
you were looking at is the one you’ve just deleted. Which means the link
is confusing because:
- you thought the thing was ‘gone’
- we’ve secretly renamed it to ‘_archived Example service name’
So this commit hides the link in this specific case.
At the moment we have a blanket rule that users can’t archive their own
services, to prevent someone accidentally deleting a real live service,
because that would be Very Bad.
But the tickets we get from users asking us to delete services are for
services they set up when they were just trying out Notify. There’s not
much harm in letting users delete these services, the consequences of
doing so are much lower than those of deleting a live service. And it
should mean fewer support tickets for us to deal with.
At the moment the only setting that a normal organisation team member
can change is the name of the organisation is its name. And we don’t
even want them to be able to change this. So this commit hides the
settings page entirely for non-platform-admin users.
If a domain is already in our organisation list then we no longer need
to manually update it here. As part of this process I went and
proactively added some organisations, so I could remove more of them
from this file. I only did this where I could clearly determine from the
domain or a suppot ticket what the organisation was.
The domains lookup is a bit slow because it’s serialising all the
organisations in the database. Since we’re putting this in the sign up
flow it should feel snappy, so lets cache just the domain bit of it in
Redis.
At the moment we have to update a YAML file and deploy the change to get
a new domain whitelisted.
We already have a thing for adding new domains – the organisation stuff.
This commit extends the validation to look in the `domains` table on the
API if it can’t find anything in the YAML whitelist.
This has the advantage of:
- not having to deploy code to whitelist a new domain
- forcing us to create new organisations as they come along, so that
users’ services automatically get allocated to the organisation once
their domain is whitelisted
first way round and then collected placeholders again. Now the flow
collects all placeholders in one round.
Also fix the back link for step-1 for test flow so it goes back
to choosing recipient number
Also move operators around following flake8's advice :)
