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
"with personalisation" should only be used by the public notification api
"with template" should be used when we want template name, etc details.
also added an xfail test for correctly constructing notification
personalisation
rename the notification_status_schema to make it apparent that it
involves the template, and then don't use it on the job page - the
job page doesn't do anything with the data. won't somebody think of
the cpu cycles! (also means it ignores problems with template
versions)
* tests on API endpoints that we do not explicitly sort should
either sort the results or compare results in an orderless way
(e.g. converting to a set)
* tests that touch the provider_details should reset values after
running, since the provider_details table is not torn down and
re-created between tests (unlike most tables)
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
Bleach 1.4.2 installs html5lib version 0.999 or greater.
This was fine, until version 0.999999999 (nine nines was released, which
doesn’t work.
Bleach 1.4.3 pins html5lib to 0.9999999 (seven nines), which stops the
bad version getting installed.
Add additional relationships to exclude in the ServiceSchema metaclass.
Marshmallow by default lazily loads relationships when dumping, so any
relationships we know we won't need, we can exclude and avoid a DB call.
Lots of tables are linked to services, so it loads a lot of tables.
So don't load statistics tables, since they're clearly not needed.
We *do* however want to return the users for the service - they're used
in a few places. If we're returning all services, then we don't want to
make separate queries for these users, so we modify the services_dao
queries to load users the first time round. This should speed up all
GET queries to the services endpoints, most notably pages that get many
services (platform_admin, choose service, login)
