On the frontend, we’re letting users register with international phone
numbers. So we shouldn’t block users from doing this on the API side.
Same thing for the whitelist, where we’re also allowing international
phone numbers now.
previously we didn't do this because the tests all used the same DB
(test_notifications_api), however @minglis shared a snippet that simply
creates one test db per thread.
This was only ever a spike into what it might look like to document
Notify’s API with Swagger (see
7c3d25a87a).
It’s no longer updated, and only talks about version 1 of the public
API.
Keeping it around now is just a liability, and gives us additional Pyup
upgrades to deal with.
specifically, all of the performance platform specific data layout now
happens in performance_platform_client.py - stuff like setting the
_timestamp, period etc, and the perf platform-specific nomenclature is
all handled there.
so that it doesn't appear generic when it's actually specific to
sending the daily notification totals. To do this, split it out into a
separate performance_platform directory, containing the business logic,
and make the performance_platform_client incredibly thin - all it
handles is adding ids to payloads, and sending stats.
Also, some changes to the config (not all done yet) since there is one
token per endpoint, not one for the whole platform as we'd previously
coded
- Created TaskNames for DVLA_FILES rather than have DVLA_FILES in QueueNames
- Removed PROCESS_FTP from all_queues() as this was causing problems in picking up letter job tasks
- Created test to ensure that we don't arbitrarily add queue names to all_queues
1. Create a separate billing blueprint to house these endpoints
2. Return monthly breakdown in same format as we did before
3. Return yearly breakdown but only return {billing units, rate,
notification_type}. Admin only makes use of these.
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.
