If we change our mind and decide whether a service should/should not be
counted in the list of live services then we should also drop the cache
which stores the count of how many live services there are.
If you’ve come from a template to add a new letter sender then it’s
because you want those words on that template. This commit adds the
extra API call to make that happen.
Most users don’t have multiple contact blocks. So by default it should
feel like you’re just editing the one contact block, rather than
managing a collection of them. So this page skips the ‘choose’ page when
the user doesn’t yet have any contact blocks.
Rather than force us to write the decorators in a specific order let’s
just have one decorator call the other. This should make fewer lines of
code, and fewer annoying test failures. It also means that the same way
of raising a `401` (through the `current_app` method) is used
everywhere.
At the moment we mostly have `user_has_permissions` execute first. It
shouldn’t matter, but it feels right for us to check that a user is
logged in before we check their permissions to a service. Otherwise a
malicious user could (maybe) check if a service ID belongs to a real
service, and go on to do something malicious with that information.
This commit adds some extra test code to enforce that the order is
always the same.
N.B. decorators in Python execute from closest to furthest (from the
line on which the function is defined).
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)
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.
"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."
Apply suggestions from code review
Reduce max verification waiting time to 90 seconds
Also minor changes following peer review
Co-Authored-By: Chris Hill-Scott <me@quis.cc>
Use constants for notification status collections on verify reply-to
email address
Use a cleaner way of adding request arguments to url_for()
AJAX requests stop on success or failure, as the waiting page
does not have to referesh any longer.
Also on failure a form that allows user to try again
is shown.
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.
Settings looked at `domains.yml` when users were making go live requests
or email branding requests.
This will allow us to remove the `domains.yml` file, by using
information about organisations that is now stored in the database
instead.
Returns the data calculated by the API. Stored in Redis against a
hardcoded key so that no-one hammering the home page is directly hitting
the database.
Adds a front end for:
https://github.com/alphagov/notifications-api/pull/2417
> Sometimes we have to make a few services for what really is one
> service, for example GOV.UK Pay and GOV.UK Pay Direct Debit. We also
> have our own test services which aren’t included in the count of live
> services. We currently count these as one service by not including
> them in the beta partners spreadsheet.
When we get a request for new branding it’s helpful to quickly see what
the service’s current branding is, so we can get a better sense of why
they want to change it.
At the moment it 500s because it can’t format the `None` values as
numbers.
In the future we will stop people requesting to go live until they’ve
provided this info. For now it has to be optional.
We get a bunch of requests to go live where people have told us they're
going to send email but there is no email reply-to address present.
These come from 2 scenarios:
1. when there are email templates, and no reply to address – but they
ignore the checklist
2. when there are no email templates (yet) but they provide anticipated
volumes for email
At the moment we only auto-check for a reply to address when they have
email templates. And because the question about anticipated volumes
follows the checklist, you'll get a checklist that passes (reply
addresses not required as no templates present) - but your future intent
that differs (reply address IS required because you have anticipated
volumes).
So let’s bring the request for anticipated volumes into the checklist,
that way we can dynamically add the requirement for a reply to address
if they say they will send email but don't have templates yet.
We should begin storing it in the database against the service to stop
people having to re-enter it each time they try to complete the go live
screens.
This also means moving the ‘consent to research question’ along with
the questions about volume, because
- we want people to answer both before going live
- we don’t want to clutter up the summary page by asking questions there
too
Most of the existing platform admin buttons on the service settings
page used to issue GET requests to switch service settings. This
means they weren't protected by CSRF. On top of that as our number
of service permissions increases over time a lot of buttons on the
page made it hard to work with.
To fix these issues we replace most of the buttons with rows in the
platform admin settings table. Each setting has a 'Change' link that
leads to a page with an On/Off switch form.
This removes "research mode" switch completely since we're planning
to deprecate it in the future and we don't expect to switch any new
services into research mode at the moment.
Most service permissions are now handled by a shared endpoint that
is parameterized with the permission name. Some permissions that
require some additional logic before they can be toggled (like document
upload, which requires setting a contact address) have separate
initial endpoints that redirect to `set_service_permission`.
"Archive", "Suspend" and "Resume" actions are kept as buttons since
they display a confirmation banner (which is a CSRF-protected form)
and they're not easily represented as an On/Off switch.
This adds a new OnOffField class that implements a boolean field
that is rendered as two On / Off radio buttons. This allows us to
avoid comparing 'on' and 'off' string values in the views since
the field takes care of transforming form data into python booleans.
This also adds a form class that can be used for any single On / Off
switch forms (e.g. service permissions).
