so they can be distinguished on the frontend.
Also, some related cleanup:
* don't show test api letters on the frontpage
* make sure the subject is returned from the API for letters
* make sure the letter's address is returned for letters
This is because 7days should be the amount of data in that table so don't restrict.
Note not all queries do this in the same way and a pivotal bug has been raised to align this. This is a bug fix as right now the numbers are out in prod.
In the future we might want to validate email addresses before
attempting to search by them. But for a first pass we can just return
no results when a user types in something that isn’t an email address
or phone number.
It definitely better than returning a 500.
- PREVIOUS
based on status. so as we add new status we have some orphaned rows, as these delete queries would miss them
- NOW
based on type. In effect they do the same thing, deleting emails, sms or letters older than a week old irrespective of status. Can see is iterating on this to have more granularity say for letters, so split up. Also means that the delete action isn't so big, as we half the affected rows, by doing it by type.
some countries don't return delivery receipts
some countries return delivery receipts when they reach the carrier
these countries, we should keep the notifications in sent (aka
sent_internatinally) for. However, for countries that have normal
delivery receipts, we should update them as we do for UK numbers
Once we have the new columns in notifications table, the query will need to include the rate multiplier and if the number is international.
The monthly billing query will be built next.
By removing the join to services for the fetch_stats_by_date_range_for_all_services and dao_fetch_todays_stats_for_all_services
queries we get a 30% and 25% performance improvement.
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.
