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.
When populating the monthly billing records on a schedule, we need
to ensure the correct month is being updated.
As an example, if the current datetime is 31 Mar 2016, 23:00. The
BST equivalent is the 1st April. Therefore we need to ensure we
update billing for April, not March. This takes care of that.
when in research mode or test key, dont send letters via api - instead,
just put them straight to success state
when using a team key, flat out reject the request (403)
This is still a work in progress but it would be good to get some eyes on it.
This commit includes creating and updating a row in the monthly billing table and a method to fetch the results.
There is a command to populate the monthly billing for a service and month so we can try it out.
The total cost at the moment are wrong, they do not take into account the free allowance - see notes below about adding that to the table.
Left to do:
create a nightly task to run to update the monthly totals.
create an endpoint to return the yearly billing, the current day will need to be calculated on the fly and added to the totals.
Add the free allowance into the total costs.
rather than using the `normalise_phone_number` function, use the
`validate_and_format_phone_number` function - this will also convert
all numbers to international format, which means we won't need to
worry about whether the user enters internaional or UK phone numbers
when searching
two endpoints:
* get all inbound sms for a service (you can limit to the X most
recent, or filter by user's phone number [which will be normalised])
* get a summary of inbound sms for a service - returns the count of
inbound sms in the database, and the date that the most recent was
sent
This will transform each notification in a job to a row in a file.
The file is then uploaded to S3.
The files will later be aggregated by the notifications-ftp app to send to dvla.
The method to upload the file to S3 should be pulled into notifications-utils package.
It is the same method used in notifications-admin.
the `to` field stores either the phone number or the email address
of the recipient - it's a bit more complicated for letters, since
there are address lines 1 through 6, and a postcode. In utils, they're
stored alongside the personalisation, and we have to ensure that when
we persist to the database we keep as much parity with utils to make
our work easier. Aside from sending, the `to` field is also used to
show recipients on the front end report pages - we've decided that the
best thing to store here is address_line_1 - which is probably going to
be either a person's name, company name, or PO box number
Also, a lot of tests and test cleanup - I added create_template and
create_notification functions in db.py, so if you're creating new
fixtures you can use these functions, and you won't need to pass
notify_db and notify_db_session around, huzzah!
also removed create param from sample_notification since it's not used
anywhere
while it's nice to use the decorator to signify fixtures with side
effects, it has unfortunate problems of completely overriding any
fixtures you've declared in the funcargs - so isn't really suitable
for our usecase where we often have other fixtures we rely on to
return values to us.
So for consistency, let's remove this and stick to using funcargs
to define our fixtures
this create_user function can be imported for use in creating specific
users in your tests, for example
```
from tests.app.db import create_user
def test_create_user_persists_to_database(notify_db_session):
user = create_user()
assert User.query.count() == 1
```
this has the benefit of not requiring you to pass the notify_db and
notify_db_session fixtures around, and separating custom object
creation from the fixture dependency trees to aid clarity
I started with sample_user since it has no downstream dependencies, but
the intention is to push this out to all db fixtures eventually. This
is a total conversion, but can be rolled out in a non-breaking manner
by keeping arguments in the fixture, and passing them through to the
new db function - then tests can be updated to use the create_* instead
of sample_* functions as and when you want to
