Checks authentication header value on inbound SMS requests from
Firetext against a list of allowed API keys set in the application
config.
At the moment, we're only logging the attempts without aborting the
requests. Once this is rolled out to production and we've checked
the logs we'll switch on the aborts and add the tests for 401 and 403
responses.
The integration tests did test for zero return. Added a method to test
for a year which has no data and also tweaked the existing tests
to ensure they are testing the year more fully.
Added a check to ensure that the current date falls in between the
financial year for the year supplied by the method, so that the todays
stats will only be appended in that situation.
correctly
The dao_fetch_monthly_historical_usage_by_template_for_service code
wasn't being tested properly due to an bug on the test which created a
notification with the same template and hence was not testing that
a specific service would have a different template id.
- Fixed the bug in the test
- Update services_dao so that the service id check is made
are not returned from queries
- Updated stats_template_usage_by_month_dao.py to return the results for
financial year not calendar, as the report os for FY only and hence
only the FY data is required
- Updated services_dao.py to ensure double precision values are converted
to an int as the 'exact' function returns double precision from the
database query, as the admin code requires the value for month to be an
int
this involved:
* moving that task to callback_tasks to prevent circular imports
* updating the dummy research mode callbacks (with actual SNS messages from the
ses simulator emails)
* refactoring tests
The check for aggregation was too broad and hence was adding together
totals based on template_id and not the unqiue combination of
template id, month and year.
- Added test to test for the failure
- Added check and a test to for template_id, mon and year matches
- Celery process name did not match the task
We have now:
- defaulted new services to start with this column set to `true`
- migrated all preexisting services[1] to have either `true` or `false` set
for this column
There is no way for a service to switch back from `true`/`false` to
`null`.
This means that we can safely enforce a non-nullable constraint on this
column now.
1. There is a little gotcha: the GOV.UK Notify service still relies on
the `sms_sender` column. It doesn’t have a row in the
`service_sms_senders` table. This means the previous migration
never changed this service’s value for `prefix_sms` from `null`. So
this commit also changes its value to `False`, so that the rest of
the migration, of the whole column, is possible.
The template name should be returned for the response and the user will
pick a year, so ths adds those two features to the
notifications/templates_usage/monthly endpoint and added some tests to
test the functionality.
Added a new endpoint which combines the usage of the stats table and the
data from the notifications tables, instead of using all the data from
the notification_history table. This should speed up the query times
and improve the page performance.
- Updated to make the stats create and update function transactional as
it actually wasn't committing the data to the table
- Added the get from the stats table
- Add a a method to combine the two results
- Added the endpoint
