1. Create a separate billing blueprint to house these endpoints
2. Return monthly breakdown in same format as we did before
3. Return yearly breakdown but only return {billing units, rate,
notification_type}. Admin only makes use of these.
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.
This is still a work in progress but it would be good to get some eyes on it.
This commit includes creating and updating a row in the monthly billing table and a method to fetch the results.
There is a command to populate the monthly billing for a service and month so we can try it out.
The total cost at the moment are wrong, they do not take into account the free allowance - see notes below about adding that to the table.
Left to do:
create a nightly task to run to update the monthly totals.
create an endpoint to return the yearly billing, the current day will need to be calculated on the fly and added to the totals.
Add the free allowance into the total costs.
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.
Marshmallow validates and deserialises - BUT, when it deserialises,
it explicitly sets `sms_sender=None`, even when you haven't passed
sms_sender in. This is problematic, because we wanted to take advantage
of sqlalchemy's default value to set sms_sender to `GOVUK` when the
actual DB commit happens.
Instead, still use marshmallow for validating, but manually carry out
the json deserialisation in the model class.
This fixes a bug that only manifested when the database was upgraded,
but the code hadn't updated. 🎉
Since the response has changed I have created new endpoints so that the deployments for Admin are more managable.
Removed print statements from some tests.
