- Modified the services_dao to return an int instead of a datetime to
make usage easier and removed the BST function on year as it is not
relevant for year
- Improved tests do there is less logic by ordering the result so there
is less reliance on the template id
- Renamed variable in stats_template_usage_by_month_dao.py to make it
consistent with the method
- Some tests for failing because of an import which was overriding the
one above it in test_scheduled_tasks.py
- Import error fixed in test_services_dao.py after a rename of a method
Currently some pages are timing out due to the time it takes to perform
database queries. This is an attempt to improve the performance by
performing the query against the notification history table once a day
and use the notification table for a delta between midnight and the when
the page is run and combine the results.
- Added Celery task for doing the work
- Added a dao to handle the insert and update of the stats table
- Updated tests to test the new functionality
We want new services, when they do the tour, to see how the service name
they just made shows up in the messages. This is how it (should) work
at the moment (although got broken because of the multiple senders
stuff).
Need to do this before we do the migration now otherwise a new service
could sneak in with this setting still set to `null`.
NotificationStatistics was added as a spike but didn't work out as expected. This is finally removing all that unused code.
I'll drop the table in the next PR
Also removed an extra query to services.
The query has been refactored to use an outer join to services on the notifications or notification_history table.
The expectation is that this change will improve the performance of the trial/live-services pages for platform admins.
- Existing test was failing as the expected results did not match when retrieving results between 11pm and 12am during bst, so time was fixed to when it wasn't affected
- New test is added to check results during the bst hour
We had these fiddly little generator expressions repeated throughout
this file. Code is made easier to understand by refactoring them into a
function that describes what it does.
International SMS is a mature, documented feature now. There’s no reason
it shouldn’t be available to everyone. If it’s turned off by default
then we’re relying on people finding it in the settings page to know
that it exists (which we found in research the other week that users,
who would have benefitted from having international SMS, were failing to
do).
This also fixes the problem whereby users signing up for Notify with an
international phone number (eg those working abroad for the Foreign and
Commonwealth Office) couldn’t get through the tour because they weren’t
able to send themselves the example text message (see
https://www.pivotaltracker.com/story/show/150705515).
This will need to be refactored after the deployment of api and admin and after the update script for existing services using inbound numbers has been executed.
I updated the InboundSms and TemplateRedacted model to include an index in the db.
Dropped service_permissions.updated_at column since we are not auditting the table
If the date range is with the last 7 days we query Notifcations.
If the date range is outside of the last 7 days we query NotificationHistory.
NotificationHistory does not persist notifications created with a test api key.
The status dictionary was being assigned once, and then subsequent
uses of it were by reference. This meant that each template type was
pointing at the same dictionary, and updating one meant updating all.
This commit adds a dictionary comprehension, which gets evaluated once
for each template type, so each template type has its own `dict` of
statuses.
Before
--
```
Email SMS Letter
| | |
{'sending':, 'failed', …}
```
After
--
```
Email SMS Letter
| | |
{'sending':, {'sending':, {'sending':,
'failed', 'failed', 'failed',
…} …} …}
```
Before we were only checking counts for SMS, because we’d only created
SMS notifications.
This commit also checks the counts for email and letter, which should be
0. But they’re not. So this commit is adding the test case which
demonstrates the bug.
This endpoint will eventualy replace the weekly breakdown one. By month
for a given financial year is better, because it gives us consistency
with the breakdown of financial usage (and eventually consistency with
the template usage).
The code to do this is a bit convoluted, in order to fill out the counts
for months and statuses where we don’t have notifications.
This will make the admin side of this easier, because we can rely on
there always being numbers available. The admin side will deal with
summing the statuses (eg `temporary-failure` > `failed`) because this
is presentational.
This commit also modifies the usage count to use `.between()` for
consistency.
- Renaming /service/<id>/deactivate to /service/<id>/archive to match language on the UI.
- Will need to update admin before deleting the deactive service method
- Created dao and endpoint methods to suspend and resume a service.
- I confirm the use of suspend and resume with a couple people on the team, seems to be the right choice.
The idea is that if you archive a service there is no coming back from that.
To suspend a service is marking it as inactive and revoking the api keys. To resume a service is to mark the service as active, the service will need to create new API keys.
It makes sense that if a service is under threat that the API keys should be renewed.
The next PR will update the code to check that the service is active before sending the request or allowing any actions by the service.
