moved format_statistics to a new service/statistics.py file, and
refactored to share code. moved tests as well, to try and enforce
separation between the restful endpoints of rest.py and the logic/
data manipulation of statistics.py
if both detailed=True and today_only=True are passed in, the stats
returned will only be for today.
if detailed is false or not specified, today_only has no effect
if passed in, returns the service object with additional statistics
dictionary, which will be used in the admin app to populate dashboard
components. A new schema has been created for this to avoid clashing/
causing confusion with the existing schema, which is already used
for PUT/POST as well, and this schema can be easily tailored to
reduce ambiguity and lazy-loading
moved from notifications/rest -> service/rest and job/rest respectively
endpoint routes not affected
removed requires_admin decorator - that should be set by nginx config
as opposed to python code
This version of the client removed the request method, path and body from the encode and decode methods.
The biggest changes here is to the unit tests.
There is a uniqueness constraint on service `name` and `email_from`.
When you try to insert a row which has _both_ constraints, there is no
guarantee which one the operation will fail on.
This means that, when handling the exception, service `name` is not
reliably available, because sometimes the operation fails on the
`email_from` constraint instead.
This caused the tests to fail non-deterministically because they were
looking for the service `name` in the error message. As a fix, this
commit does two things:
1. Return either the service `name` or `email_from` in the error
message, depending which is available.
2. Modify the test to pass on _either_ of the two possible error
messages.
This is not ideal, but I can’t think of a way to maintain the original
behaviour, and have reliably passing tests.
adapted to recording inserts and updates.
This removes need to manually create history tables.
Our code still remains in control of when history records are
created.
Removed the validation in the schema - it was adding complexity, let the unique constraint on the db throw the exception. This should only ever happen on a race condition which seems unlikely (two people changing a service to the same name at the same time)
Do no set debug=true to the test config. If debug=true it changes the behaviour of the error handlers, throwing the exception rather than returning a 500.
This PR removes the need for the email_safe function. The api does not create the email_from field for the service.
Tests were updated to reflect this change.
Refactored service/rest.py so that all methods are returning a properly formatted error message so that the error message can deal with the response.
Refactoed errors.py to properly format the error message.
Added a test for when there are no users for the service.
Added a test_url_for - do we want to add this test and use url_for in our tests?
Or explictly write the url in the test?
Ideally all the primary keys in the db would be UUID in order to guarantee unique ids across distributed dbs.
This updates the services.id to a UUID. All the tables with a foreign key to the services.id are also updated.
The endpoints no longer state a data type of the <service_id> path param.
All the tests are updated to reflect this update.
The thing to pay attention to is the 0011_uuid_service_id.py migration script.
This commit must go with a commit on the notifications_admin app to keep things working.
There will be a small outage until both deploys have happened.
