The clients never get passed useful values to their `__init__` methods.
Rather the real values are passed through later using the `init_app`
method.
So it should be an error if the client is relying on the values that
get passed to it’s init method. Easiest way to ensure this is by making
the `__init__` method not expect any arguments and passing fake values
to the `Super` call.
If you schedule a job you might change your mind or circumstances might
change. So you need to be able to cancel it. This commit adds a button
on the job page which hits the `…/cancel` API endpoint for a job.
The create job endpoint returns the data about the job with a `data:`
wrapper. This commit makes sure that, when the client is trying to
process a job which has just been created, it looks inside the `data`
wrapper.
Users need to pick a time in the next 24hrs, or send a file immediately.
Rationale for this is a bit lost in time-before-holiday, but generally:
‘Now’ and ‘later’ as the inital choices makes it really clear what
this feature is about conceptually.
The choice of times is absolute, eg ‘1pm’ not ‘in 3 hours’
This is just some refactoring.
`defaultdict` is a data structure which won’t raise a `KeyError` if you
try to access a key that doesn’t exist.
By passing `int` as the first argument, trying to access the value of
any key that doesn’t exists will return the value of `int()`, ie `0`
It’s useful to know how many notifications we’ve handed off to our
providers. This is a measure of how complete the processing of the job
is.
This is important, because once the job processing is complete then you
can accurately reconcile the report with the CSV file that you’ve
uploaded.
We changed the `update_service` method to only update indivdual
attributes of a service, and only allow it to update specified
attributes: 0cfe10639a
We neglected to specify `research_mode` as one of the allowed
attributes.
This broke the app’s ability to put a service in or out of research
mode.
This commit:
- makes sure the tests cover this eventuality
- fixes the bug by specifying `research_mode` as one of the allowed
attributes
Mutating dictionaries is gross and doesn’t work as you’d expect. Better
to have the function return a new dictionary instead.
Means we can be explicit that `created_by` is one of the allowed params
when updating a service.
To prevent typos and inadvertently updating something we shouldn’t,
this adds some filtering to the update_service method to make sure it
is only allowed to update certain attributes of a service.
The service API client was updating every attribute of a service. Which,
while kinda clunky, is fine…
…until something calling it doesn’t pass in every attribute of the
current service. It was then defaulting optional parameters to `None`.
Which resulted in a bug whereby every time a service was set to live,
its `reply_to_address` and `sms_sender_name` got overwritten to be
empty.
This commit changes the `update` method to only require the service ID,
and pass whatever other named arguments it received straight through to
the API. The API handles partial updates just fine (I think).
