We’re going to have different allowances next financial year. This means
that when someone adds a service, we’ll need to check which year it is,
so we can give them the right allowance.
This commit changes the config structure so that the current allowances
are explicitly assigned to the 2020/21 financial year.
It freezes the tests to the 2020/21 financial year, so they won’t start
failing automatically when next financial year comes around.
This adds an audit event to the `events` table when the broadcast
permissions for a service (the service mode, channel or provider
restriction) changes.
Sometimes we get a service ID from a support ticket or a Slack
discussion. Rather than having to hack the URL, this PR augments the
‘Find services by name’ page to support service IDs. If a UUID is
entered, it assumes that it’s been given a service ID, and redirects
straight to the dashboard for that service, without showing any search
results (a complete UUID would never match multiple services). If the
UUID is not a service ID, the user will get a 404.
The links in the blue boxes on the job page needed hidden text so that
they work out of context. This changes the text from "10 sending" to "10
sending text messages" (with the message type hidden text).
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
This makes the preview of the email / SMS to send consistent with
the final screen, which we previously changed to show the "reply
to" text irrespective of whether the user had selected anything.
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.
