The ‘make this default’ checkbox should be shown, except when:
- the user is adding their first email reply to address (because the
first one has to be the default)
- they’re editing the existing default (because they can’t change it
to be not default)
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 :)
"Failure is slower than success. So the longer a notification
takes to get a status, the more likely it is for that status
to be a failure anyway. This increases dramatically after 45 seconds.
The percentage of emails that go to delivered in less than 90 seconds
is 98.92%. To get to 99% we’d need to increase the timeout
to 178 seconds (3 minutes). We could still get 98.7% of notifications
by dropping the timeout to 45 seconds, and improve the experience
for notifications that are likely to fail by returning an error more quickly."
For accessibility reasons a page should have one (and only one) H1. This
commit fixes an instance where the H1 was duplicated as a result of the
work done to componentize our page headings.
It also adds an extra check to `client_request` so that we don’t
introduce pages with multiple or no H1s in the future.
This removes the edit_folder_permission checks from the code, enabling
the folder permissions for all services.
This also fixes folder-related tests to set up appropriate user
permissions.
This should only be merged right after alphagov/notifications-api#2428,
when all other permission stories are done.
Platform admin users can access all template folders, so the folder
permissions form always displays everything as checked for them,
which makes it look like the form isn't actually working. We could
do the check based on folder data, but the field still wouldn't
have any effect on permissions. So instead, we hide it completely
for platform admin users.
Submitting the form will remove any folder permissions from the DB
for the platform admin user (which can still be created by changing
permissions on the template folder 'Manage' page), but that's only
relevant if a user stops being a platform admin but keeps their
Notify services.
If we can’t guess a user’s organisation then they have to choose what
type of organisation they work for when they add a new service. This
commit adds a test to make sure they can’t just click the green button
and proceed without picking one.
- This brings in the latest version of notifications-utils which
allows Welsh characters in SMS templates.
- Updated the pricing page to show the new prices for SMS with certain
Welsh characters
