note that all of these tests have to be checked to ensure that they
still call through to notify_db_session (notify_db not required) to
tear down the database after the test runs - since it's no longer
required to pass it in to the function just to invoke the sample_user
function
When the start_date and end_date query argruments exists in the request,
the query will return the results from the NotificationHistory table for the given date range.
We will need to check the performance of this query, but this will only be used by the platform admin page.
We want to be able to toggle the numbers on the platform admin page between
including and excluding notifications sent using test keys, so that we can see
both real use of the platform and all load on it.
This parameter defaults to True, which is the existing behaviour.
`/services/ef7a665d-11a4-425a-a180-a67ca00b69d7/billable-units?year=2016`
Pretty much just passes through to the DAO layer. Validates that year
is:
- present (there’s no need for unbounded queries on this endpoint)
- an integer
This commit adds the `include_jobs` filter to the
`GET /services/…/notifications` endpoint. It defaults to `True` (ie show
all notifications) but makes it possible to only return notifications
created by _any_ API key.
This is so that we can show a log of all notifications sent through the
API in the admin app.
It does not expose this list to the public `GET /notifications` endpoint
because this would violate our rules about keys only being able to get
notifications created with keys of the same type.
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.
