persist_letter saves address correctly to database
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
2017-01-19 12:10:32 +00:00
|
|
|
from datetime import datetime
|
|
|
|
|
import uuid
|
|
|
|
|
|
2017-05-24 14:24:57 +01:00
|
|
|
|
2017-03-15 15:26:58 +00:00
|
|
|
from app.dao.jobs_dao import dao_create_job
|
2017-05-24 14:24:57 +01:00
|
|
|
from app.models import (
|
|
|
|
|
Service,
|
|
|
|
|
User,
|
|
|
|
|
Template,
|
|
|
|
|
Notification,
|
|
|
|
|
ScheduledNotification,
|
|
|
|
|
ServicePermission,
|
|
|
|
|
Job,
|
|
|
|
|
EMAIL_TYPE,
|
|
|
|
|
SMS_TYPE,
|
|
|
|
|
KEY_TYPE_NORMAL,
|
|
|
|
|
)
|
2016-12-28 12:30:21 +00:00
|
|
|
from app.dao.users_dao import save_model_user
|
2017-05-25 11:41:07 +01:00
|
|
|
from app.dao.notifications_dao import dao_create_notification, dao_created_scheduled_notification
|
persist_letter saves address correctly to database
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
2017-01-19 12:10:32 +00:00
|
|
|
from app.dao.templates_dao import dao_create_template
|
2017-02-16 11:55:52 +00:00
|
|
|
from app.dao.services_dao import dao_create_service
|
2017-05-17 14:09:18 +01:00
|
|
|
from app.dao.service_permissions_dao import dao_add_service_permission
|
2016-12-28 12:30:21 +00:00
|
|
|
|
|
|
|
|
|
2017-05-10 15:58:44 +01:00
|
|
|
def create_user(mobile_number="+447700900986", email="notify@digital.cabinet-office.gov.uk", state='active'):
|
2016-12-28 12:30:21 +00:00
|
|
|
data = {
|
2017-05-10 15:58:44 +01:00
|
|
|
'id': uuid.uuid4(),
|
2016-12-28 12:30:21 +00:00
|
|
|
'name': 'Test User',
|
|
|
|
|
'email_address': email,
|
|
|
|
|
'password': 'password',
|
|
|
|
|
'mobile_number': mobile_number,
|
2017-05-10 15:58:44 +01:00
|
|
|
'state': state
|
2016-12-28 12:30:21 +00:00
|
|
|
}
|
2017-01-10 15:00:10 +00:00
|
|
|
user = User.query.filter_by(email_address=email).first()
|
|
|
|
|
if not user:
|
|
|
|
|
user = User(**data)
|
|
|
|
|
save_model_user(user)
|
|
|
|
|
return user
|
persist_letter saves address correctly to database
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
2017-01-19 12:10:32 +00:00
|
|
|
|
|
|
|
|
|
2017-05-17 14:09:18 +01:00
|
|
|
def create_service(
|
2017-05-17 16:06:35 +01:00
|
|
|
user=None, service_name="Sample service", service_id=None, restricted=False,
|
|
|
|
|
service_permissions=[EMAIL_TYPE, SMS_TYPE]):
|
2017-02-16 11:55:52 +00:00
|
|
|
service = Service(
|
|
|
|
|
name=service_name,
|
|
|
|
|
message_limit=1000,
|
2017-05-12 14:07:06 +01:00
|
|
|
restricted=restricted,
|
2017-02-16 11:55:52 +00:00
|
|
|
email_from=service_name.lower().replace(' ', '.'),
|
|
|
|
|
created_by=user or create_user()
|
|
|
|
|
)
|
2017-05-17 14:09:18 +01:00
|
|
|
dao_create_service(service, service.created_by, service_id, service_permissions=service_permissions)
|
2017-02-16 11:55:52 +00:00
|
|
|
return service
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def create_template(
|
|
|
|
|
service,
|
|
|
|
|
template_type=SMS_TYPE,
|
2017-04-06 12:10:06 +01:00
|
|
|
subject='Template subject',
|
2017-02-24 13:39:58 +00:00
|
|
|
content='Dear Sir/Madam, Hello. Yours Truly, The Government.',
|
|
|
|
|
template_id=None
|
2017-02-16 11:55:52 +00:00
|
|
|
):
|
persist_letter saves address correctly to database
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
2017-01-19 12:10:32 +00:00
|
|
|
data = {
|
|
|
|
|
'name': '{} Template Name'.format(template_type),
|
|
|
|
|
'template_type': template_type,
|
2017-02-16 11:55:52 +00:00
|
|
|
'content': content,
|
persist_letter saves address correctly to database
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
2017-01-19 12:10:32 +00:00
|
|
|
'service': service,
|
|
|
|
|
'created_by': service.created_by,
|
|
|
|
|
}
|
|
|
|
|
if template_type != SMS_TYPE:
|
2017-04-06 12:10:06 +01:00
|
|
|
data['subject'] = subject
|
persist_letter saves address correctly to database
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
2017-01-19 12:10:32 +00:00
|
|
|
template = Template(**data)
|
2017-03-08 13:03:44 +00:00
|
|
|
dao_create_template(template)
|
persist_letter saves address correctly to database
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
2017-01-19 12:10:32 +00:00
|
|
|
return template
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def create_notification(
|
|
|
|
|
template,
|
|
|
|
|
job=None,
|
|
|
|
|
job_row_number=None,
|
|
|
|
|
to_field='+447700900855',
|
|
|
|
|
status='created',
|
|
|
|
|
reference=None,
|
|
|
|
|
created_at=None,
|
|
|
|
|
sent_at=None,
|
2017-02-24 13:39:58 +00:00
|
|
|
updated_at=None,
|
persist_letter saves address correctly to database
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
2017-01-19 12:10:32 +00:00
|
|
|
billable_units=1,
|
|
|
|
|
personalisation=None,
|
|
|
|
|
api_key_id=None,
|
|
|
|
|
key_type=KEY_TYPE_NORMAL,
|
|
|
|
|
sent_by=None,
|
2017-04-27 12:14:31 +01:00
|
|
|
client_reference=None,
|
2017-04-27 15:43:57 +01:00
|
|
|
rate_multiplier=None,
|
|
|
|
|
international=False,
|
2017-05-25 11:41:07 +01:00
|
|
|
phone_prefix=None,
|
2017-05-24 14:24:57 +01:00
|
|
|
scheduled_for=None,
|
|
|
|
|
normalised_to=None
|
persist_letter saves address correctly to database
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
2017-01-19 12:10:32 +00:00
|
|
|
):
|
|
|
|
|
if created_at is None:
|
|
|
|
|
created_at = datetime.utcnow()
|
2017-02-24 13:39:58 +00:00
|
|
|
|
2017-02-27 13:16:48 +00:00
|
|
|
if status != 'created':
|
|
|
|
|
sent_at = sent_at or datetime.utcnow()
|
|
|
|
|
updated_at = updated_at or datetime.utcnow()
|
2017-02-24 13:39:58 +00:00
|
|
|
|
persist_letter saves address correctly to database
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
2017-01-19 12:10:32 +00:00
|
|
|
data = {
|
|
|
|
|
'id': uuid.uuid4(),
|
|
|
|
|
'to': to_field,
|
|
|
|
|
'job_id': job.id if job else None,
|
|
|
|
|
'job': job,
|
2017-04-19 13:49:10 +01:00
|
|
|
'service_id': template.service.id,
|
2017-02-16 11:55:52 +00:00
|
|
|
'service': template.service,
|
persist_letter saves address correctly to database
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
2017-01-19 12:10:32 +00:00
|
|
|
'template_id': template.id if template else None,
|
|
|
|
|
'template': template,
|
|
|
|
|
'template_version': template.version,
|
|
|
|
|
'status': status,
|
|
|
|
|
'reference': reference,
|
|
|
|
|
'created_at': created_at,
|
|
|
|
|
'sent_at': sent_at,
|
|
|
|
|
'billable_units': billable_units,
|
|
|
|
|
'personalisation': personalisation,
|
|
|
|
|
'notification_type': template.template_type,
|
|
|
|
|
'api_key_id': api_key_id,
|
|
|
|
|
'key_type': key_type,
|
|
|
|
|
'sent_by': sent_by,
|
2017-02-24 13:39:58 +00:00
|
|
|
'updated_at': updated_at,
|
persist_letter saves address correctly to database
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
2017-01-19 12:10:32 +00:00
|
|
|
'client_reference': client_reference,
|
2017-04-27 12:14:31 +01:00
|
|
|
'job_row_number': job_row_number,
|
2017-04-27 15:43:57 +01:00
|
|
|
'rate_multiplier': rate_multiplier,
|
|
|
|
|
'international': international,
|
2017-05-24 14:24:57 +01:00
|
|
|
'phone_prefix': phone_prefix,
|
|
|
|
|
'normalised_to': normalised_to
|
persist_letter saves address correctly to database
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
2017-01-19 12:10:32 +00:00
|
|
|
}
|
|
|
|
|
notification = Notification(**data)
|
|
|
|
|
dao_create_notification(notification)
|
2017-05-25 11:41:07 +01:00
|
|
|
if scheduled_for:
|
|
|
|
|
scheduled_notification = ScheduledNotification(id=uuid.uuid4(),
|
|
|
|
|
notification_id=notification.id,
|
|
|
|
|
scheduled_for=datetime.strptime(scheduled_for,
|
|
|
|
|
"%Y-%m-%d %H:%M"))
|
|
|
|
|
if status != 'created':
|
|
|
|
|
scheduled_notification.pending = False
|
|
|
|
|
dao_created_scheduled_notification(scheduled_notification)
|
persist_letter saves address correctly to database
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
2017-01-19 12:10:32 +00:00
|
|
|
return notification
|
2017-03-15 15:26:58 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
def create_job(template,
|
|
|
|
|
notification_count=1,
|
|
|
|
|
created_at=None,
|
|
|
|
|
job_status='pending',
|
|
|
|
|
scheduled_for=None,
|
|
|
|
|
processing_started=None,
|
|
|
|
|
original_file_name='some.csv'):
|
|
|
|
|
|
|
|
|
|
data = {
|
|
|
|
|
'id': uuid.uuid4(),
|
|
|
|
|
'service_id': template.service_id,
|
|
|
|
|
'service': template.service,
|
|
|
|
|
'template_id': template.id,
|
|
|
|
|
'template_version': template.version,
|
|
|
|
|
'original_file_name': original_file_name,
|
|
|
|
|
'notification_count': notification_count,
|
|
|
|
|
'created_at': created_at or datetime.utcnow(),
|
|
|
|
|
'created_by': template.created_by,
|
|
|
|
|
'job_status': job_status,
|
|
|
|
|
'scheduled_for': scheduled_for,
|
|
|
|
|
'processing_started': processing_started
|
|
|
|
|
}
|
|
|
|
|
job = Job(**data)
|
|
|
|
|
dao_create_job(job)
|
|
|
|
|
return job
|
2017-05-11 15:22:58 +01:00
|
|
|
|
|
|
|
|
|
2017-05-16 10:57:57 +01:00
|
|
|
def create_service_permission(service_id, permission=EMAIL_TYPE):
|
2017-05-17 14:09:18 +01:00
|
|
|
dao_add_service_permission(
|
2017-05-16 10:57:57 +01:00
|
|
|
service_id if service_id else create_service().id, permission)
|
2017-05-11 15:22:58 +01:00
|
|
|
|
|
|
|
|
service_permissions = ServicePermission.query.all()
|
|
|
|
|
|
|
|
|
|
return service_permissions
|