Removed the tests for trial mode service for the scheduled tasks and the process job.
Having the validation in the POST notification and create job endpoint is enough.
Updated the test_service_whitelist test because the order of the array is not gaurenteed.
On the frontend, we’re letting users register with international phone
numbers. So we shouldn’t block users from doing this on the API side.
Same thing for the whitelist, where we’re also allowing international
phone numbers now.
1. For both email and sms, store [] in monthly_totals if
there is no billing data (no notifications sent etc.) and
return this via the API
2. General refactoring of indentation
Why is this needed?
When a user updates a service name they enter the new name in a form, are then asked to confirm the change by entering their password. Then the API call to update_service is called. If we let the update serivce API call fail with the integrity constraint it will be ackward for the user.
So that when the admin gets notifications, the template they return
also has a "redact_personalisation" boolean attached to it. Note, it
won't do the redacting on the api - that'll be part of the admin.
Under the hood, this uses an association_proxy, which is essentially
black magic. But it proxies the `redact_personalisation` property of
`TemplateRedacted` onto the `Template` object, so that Marshmallow
can pick it up.
Note: NOT currently added to NotificationWithTemplateHistory
* Alter config so an error will be raised if you forget to mock out a
celery call in one of your tests
* Remove an unneeded exception type that was masking errors
currently, they're made by creating a one-line job, but we want to
reduce task/csv file noise so we're moving them to persist in the
same vein as API usage. However, we can't just call through to that
since there are some differences:
* no api keys
* tighter control over API format
* no scheduling
* no client references
etc.
So, re-using as much of the v2 validation stuff as possible, I've
created this file that just does basic validation, and then calls
through to persist_notification and schedules a task. Woo.
We need this for the two way stuff in the admin app.
We already have this as a public endpoint, but the admin app can’t use
it, because the admin app auths with its own key, not that of the
service it’s acting on behalf of.
This endpoint makes sure that a request originating from one service
can’t be used to see notifications belonging to another service.
This allows us to reference it across the API code base and return it in the API.
But not currently attached to the service DB model - a static method on the class.
