This naming was introduced in 2016 without explanation [1]. I find it
confusing because:
- It's reminiscent of "_app", which is a Python convention indicating
the variable is internal, so maybe avoid using it.
- It suggests there's some other "app" fixture I should be using (there
isn't, though).
The Python style guide describes using an underscore suffix to avoid
clashes with inbuilt names [1], which is sort of applicable if we need
to import the "app" module [2]. However, we can also avoid clashes by
choosing a different name, without the strange underscore.
[1]: 3b1d521c10
[2]: 78824f54fd/tests/app/main/views/test_forgot_password.py (L5)
Adding ‘all networks’ whenever we mention the using the test channel
without a restriction to a single network should help reinforce that
this sends real alerts.
Only the test channel has the option to isolate messages to one network.
This commits makes the choices less confusing by only showing the
network choice to those who have selected the test channel.
We have been asked to support the government channel so that:
- it can be tested
- the option to use it is available for the most severe of emergencies,
where the public’s choice to opt-out is outweighed by the widespread
risk to life
It feels quite dangerous that it’s just one click to make an emergency
alerts service live.
This commit adds a confirmation step which explains the consequences of
what you’re about to do.
The current_service.allowed_broadcast_provider is now always "all" or
one of the four providers, which means we can simply the code by not
checking if it is None.
Until all the data is updated to always be "all", we have to handle the
case of provider_restriction being set to None or "all" (which mean the
same thing).
The code can be tidied up once the broadcast provider_restriction is never None.
We're replacing the value of None with the value of all. API has been
updated to accept both values
(1767535def)
so this change starts sending notifications-api the value of "all".
This is the first step in making the UI easier for setting the
options for a broadcast service. Here we remove the options for
"Training mode" test channels. When we create a broadcast message for a trail mode service it is marked as stubbed and does not create a broadcast event that is sent to a provider.
The label for the form and setting page have been updated to reflect the
change.
This adds an audit event to the `events` table when the broadcast
permissions for a service (the service mode, channel or provider
restriction) changes.
All services have the `upload_document` permission now, so we don't need
to check for it on the email formatting page. This also deletes a test
which is not needed now.
Moves a commonly used fixture into
`mock_get_service_settings_page_common` so we don't need to keep writing
it every time.
Note, we may be able to do similar in the future with
- single_reply_to_email_address
- single_letter_contact_block
- single_sms_sender
but need a bit more thought about fixing tests that would fail due to
this change and need tweaks to the order of their arguments.
Note, no option at the moment to set the service broadcast account type
as None, or back to without the broadcast permission. This has been done
for speed of development given the chance of us needing this is very
low. We can add it later if we need to.
This is not relevant for broadcast services. This information is
given in the heading bar next to the service name. There is no process
to request to go live and it is not necessary to tell you again that the
service is live
A few of note
Count in list of live services - this should be set to no in the API (to
be implemented) so we never show broadcast services in the list of live
services to reduce security leaks
Organisation - all broadcast services are currently going to be found in
a single organisation so we keep track of them easily. Therefore there
is no need to allow the changing of the organisation
Email authentication - we may in time not allow these services to use
email auth to log in but this hasn't been decided so let's keep it for
the moment
Rate limit - although a service may end up using our API to create
broadcasts, there is currently no rate limit check on this endpoint
and it's also extremely unlikely that any service would ever breach
the default limit
As per ticket and as per Caley's request, so everything can be
edited together.
Also pluralise labels for billing contact info, to indicate
that putting multiple in is ok, and widen the input fields so
that it is more comfortable to input multiple contact details.
Update all methods that were previous calling @cache.delete('service-{service-id}-template-None') to instead call _delete_template_cache_for_service
Remove call to get service templates, it's not needed since all template version cache is being deleted.
We have lots of functions for converting various types of data into
strings to be displayed to the user somewhere.
This commit collects all these functions into their own module, rather
than having them cluttering up `app/__init__.py` or buried amongst
various other things that have ended up in `app/utils.py`.
It’s one of the things we check when someone makes a request to go live,
and putting it in the ticket means we don’t have to take the extra step
of clicking into the settings.
Also added some line breaks to chunk things up a bit more clearly.
There was a recent error in the logs because a service tried to change
its name to one exceeding 255 characters (which is a limit on the
database field). We can easily catch these errors on the form, so that
the user doesn't see an error page.
The `post` method of the `client_request` fixture has an argument called
`_data`. There were a few places where we had used an argument of `data`
instead by mistake.
Includes changing form.enabled to use
OnOffField, for consistency with other on/off
fields.
OnOffField's data is a boolean, not a string, so
some of the logic using it needed to be changed.
Live services shouldn't be able to request to go live again. Once a
service is live we remove the option to go live from the Settings page,
but we still link to the page to request to go live from other places
e.g. the 'Get started' page. As a result, we've seen some services make
another request to go live when their service has already been live for
months - this change will stop that from happening.
