We were using two different queries to filter template stats to the past
7 days, plus today.
Since we’re storing both as short dates, we can now use the same query
for both.
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7
-------|---------|-----------|----------|--------|----------|--------|-------
Monday | Tuesday | Wednesday | Thursday | Friday | Saturday | Sunday | Monday
So if we are on Monday, the stats should include today, plus everything
back to last Monday.
Previously the template stats query was only going back to the Tuesday.
This should mean the numbers on the dashboard always line up.
This means we will retain notifications for a full week and not
delete records that are 7 x 24 hours older than the time of the run of
the deletion task.
Also the task only needs to run once a day now, so I have changed
the celery config for the deletion tasks.
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.
https://www.pivotaltracker.com/story/show/117920839
On the dashboard we want to show counts of notifications sent in the
last 7 days, plus today. So the API enpoint needs to accept an argument
to limit how many days worth of statistics it will return.
This is a bit fiddly at the DAO level because the date is just stored as
a string.
- when a provider callback occurs and we update the status of the notification, also update the statistics table
Adds:
- Mapping object to the clients to handle mapping to various states from the response codes, this replaces the map.
- query lookup in the DAO to get the query based on response type / template type
Tests around rest class and dao to check correct updating of stats
Missing:
- multiple client callbacks will keep incrementing the counts of success/failure. This edge case needs to be handle in a future story.
- SES sends a reference to allow us to identify the notification
- use this to update status
If source of email is one of our internal emails (invites or validations) - don't try and update a notification.
- client updated to raise errors with fire text error codes/messages
New endpoint
- /notifications/sms/firetext
For delivery notifications to be sent to.
- rate limiting is a hard number per day
- not limited in terms of rate of request
- limit is a single number held against the service
- every notification counts against the limit, regardless of type
- return a 429 if limit exceeded.
- to capture the counts of things that we do
- initial commit captures when we create an email or sms
DOES NOT know about ultimate success only that we asked our partners to ship the notification
Requires some updates when we retry sending in event of error.
