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-07-25 11:43:41 +01:00
|
|
|
from app import db
|
2017-03-15 15:26:58 +00:00
|
|
|
from app.dao.jobs_dao import dao_create_job
|
2017-06-15 11:32:51 +01:00
|
|
|
from app.dao.service_inbound_api_dao import save_service_inbound_api
|
2017-05-24 14:24:57 +01:00
|
|
|
from app.models import (
|
2017-08-02 11:14:05 +01:00
|
|
|
ApiKey,
|
2017-08-10 16:37:30 +01:00
|
|
|
EMAIL_TYPE,
|
|
|
|
|
SMS_TYPE,
|
|
|
|
|
KEY_TYPE_NORMAL,
|
2017-05-24 14:24:57 +01:00
|
|
|
Service,
|
|
|
|
|
User,
|
|
|
|
|
Template,
|
2017-08-10 16:37:30 +01:00
|
|
|
MonthlyBilling,
|
2017-05-24 14:24:57 +01:00
|
|
|
Notification,
|
|
|
|
|
ScheduledNotification,
|
|
|
|
|
ServicePermission,
|
2017-07-18 18:21:35 +01:00
|
|
|
Rate,
|
2017-05-24 14:24:57 +01:00
|
|
|
Job,
|
2017-06-02 12:21:12 +01:00
|
|
|
InboundSms,
|
2017-08-03 14:05:13 +01:00
|
|
|
InboundNumber,
|
2017-07-04 17:02:28 +01:00
|
|
|
Organisation,
|
2017-08-16 12:27:42 +01:00
|
|
|
EMAIL_TYPE,
|
|
|
|
|
SMS_TYPE,
|
|
|
|
|
INBOUND_SMS_TYPE,
|
|
|
|
|
KEY_TYPE_NORMAL,
|
|
|
|
|
ServiceInboundApi)
|
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
|
2017-05-31 14:49:14 +01:00
|
|
|
from app.dao.inbound_sms_dao import dao_create_inbound_sms
|
2017-07-04 17:02:28 +01:00
|
|
|
from app.dao.organisations_dao import dao_create_organisation
|
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-22 11:26:47 +01:00
|
|
|
user=None,
|
|
|
|
|
service_name="Sample service",
|
|
|
|
|
service_id=None,
|
|
|
|
|
restricted=False,
|
|
|
|
|
service_permissions=[EMAIL_TYPE, SMS_TYPE],
|
2017-07-31 18:28:00 +01:00
|
|
|
sms_sender='testing',
|
|
|
|
|
research_mode=False,
|
|
|
|
|
active=True,
|
2017-08-16 12:27:42 +01:00
|
|
|
do_create_inbound_number=True,
|
2017-05-22 11:26:47 +01:00
|
|
|
):
|
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(' ', '.'),
|
2017-05-22 11:26:47 +01:00
|
|
|
created_by=user or create_user(),
|
2017-07-31 18:28:00 +01:00
|
|
|
sms_sender=sms_sender,
|
2017-02-16 11:55:52 +00:00
|
|
|
)
|
2017-08-16 12:27:42 +01:00
|
|
|
|
2017-08-23 11:09:54 +01:00
|
|
|
dao_create_service(service, service.created_by, service_id, service_permissions=service_permissions)
|
|
|
|
|
|
2017-08-16 12:27:42 +01:00
|
|
|
if do_create_inbound_number and INBOUND_SMS_TYPE in service_permissions:
|
|
|
|
|
create_inbound_number(number=sms_sender, service_id=service.id)
|
|
|
|
|
|
2017-07-31 18:28:00 +01:00
|
|
|
service.active = active
|
|
|
|
|
service.research_mode = research_mode
|
|
|
|
|
|
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,
|
2017-08-02 15:35:56 +01:00
|
|
|
api_key=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
|
|
|
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,
|
2017-08-29 16:26:55 +01:00
|
|
|
normalised_to=None,
|
|
|
|
|
one_off=False,
|
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
|
|
|
|
2017-08-29 16:26:55 +01:00
|
|
|
if not one_off and (job is None and api_key is None):
|
2017-08-02 11:14:05 +01:00
|
|
|
# we didn't specify in test - lets create it
|
2017-08-02 15:35:56 +01:00
|
|
|
api_key = ApiKey.query.filter(ApiKey.service == template.service, ApiKey.key_type == key_type).first()
|
|
|
|
|
if not api_key:
|
|
|
|
|
api_key = create_api_key(template.service, key_type=key_type)
|
2017-08-02 11:14:05 +01: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,
|
2017-08-02 15:35:56 +01:00
|
|
|
'job_id': job and job.id,
|
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
|
|
|
'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,
|
2017-08-02 15:35:56 +01:00
|
|
|
'template_id': template and template.id,
|
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,
|
|
|
|
|
'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,
|
2017-08-02 15:35:56 +01:00
|
|
|
'api_key': api_key,
|
|
|
|
|
'api_key_id': api_key and api_key.id,
|
|
|
|
|
'key_type': api_key.key_type if api_key else key_type,
|
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
|
|
|
'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
|
|
|
|
|
|
|
|
|
2017-06-02 12:21:12 +01: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'
|
|
|
|
|
):
|
2017-03-15 15:26:58 +00:00
|
|
|
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
|
2017-05-31 14:49:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
def create_inbound_sms(
|
|
|
|
|
service,
|
|
|
|
|
notify_number=None,
|
2017-06-02 12:57:28 +01:00
|
|
|
user_number='447700900111',
|
2017-05-31 14:49:14 +01:00
|
|
|
provider_date=None,
|
|
|
|
|
provider_reference=None,
|
2017-06-05 13:10:54 +01:00
|
|
|
content='Hello',
|
2017-06-09 11:56:32 +01:00
|
|
|
provider="mmg",
|
2017-06-02 12:21:12 +01:00
|
|
|
created_at=None
|
2017-05-31 14:49:14 +01:00
|
|
|
):
|
|
|
|
|
inbound = InboundSms(
|
|
|
|
|
service=service,
|
2017-06-02 12:21:12 +01:00
|
|
|
created_at=created_at or datetime.utcnow(),
|
2017-05-31 14:49:14 +01:00
|
|
|
notify_number=notify_number or service.sms_sender,
|
|
|
|
|
user_number=user_number,
|
|
|
|
|
provider_date=provider_date or datetime.utcnow(),
|
|
|
|
|
provider_reference=provider_reference or 'foo',
|
|
|
|
|
content=content,
|
2017-06-05 13:10:54 +01:00
|
|
|
provider=provider
|
2017-05-31 14:49:14 +01:00
|
|
|
)
|
|
|
|
|
dao_create_inbound_sms(inbound)
|
|
|
|
|
return inbound
|
2017-06-15 11:32:51 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
def create_service_inbound_api(
|
|
|
|
|
service,
|
|
|
|
|
url="https://something.com",
|
|
|
|
|
bearer_token="some_super_secret",
|
|
|
|
|
):
|
|
|
|
|
service_inbound_api = ServiceInboundApi(service_id=service.id,
|
|
|
|
|
url=url,
|
|
|
|
|
bearer_token=bearer_token,
|
|
|
|
|
updated_by_id=service.users[0].id
|
|
|
|
|
)
|
|
|
|
|
save_service_inbound_api(service_inbound_api)
|
|
|
|
|
return service_inbound_api
|
2017-07-04 17:02:28 +01:00
|
|
|
|
|
|
|
|
|
2017-07-05 11:17:03 +01:00
|
|
|
def create_organisation(colour='blue', logo='test_x2.png', name='test_org_1'):
|
2017-07-04 17:02:28 +01:00
|
|
|
data = {
|
|
|
|
|
'colour': colour,
|
|
|
|
|
'logo': logo,
|
|
|
|
|
'name': name
|
|
|
|
|
}
|
|
|
|
|
organisation = Organisation(**data)
|
|
|
|
|
dao_create_organisation(organisation)
|
|
|
|
|
|
|
|
|
|
return organisation
|
2017-07-18 18:21:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
def create_rate(start_date, value, notification_type):
|
2017-08-10 16:37:30 +01:00
|
|
|
rate = Rate(
|
|
|
|
|
id=uuid.uuid4(),
|
|
|
|
|
valid_from=start_date,
|
|
|
|
|
rate=value,
|
|
|
|
|
notification_type=notification_type
|
|
|
|
|
)
|
2017-07-25 11:43:41 +01:00
|
|
|
db.session.add(rate)
|
|
|
|
|
db.session.commit()
|
2017-07-18 18:21:35 +01:00
|
|
|
return rate
|
2017-08-02 11:14:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
def create_api_key(service, key_type=KEY_TYPE_NORMAL):
|
2017-08-02 15:35:56 +01:00
|
|
|
id_ = uuid.uuid4()
|
2017-08-02 11:14:05 +01:00
|
|
|
api_key = ApiKey(
|
|
|
|
|
service=service,
|
2017-08-02 15:35:56 +01:00
|
|
|
name='{} api key {}'.format(key_type, id_),
|
2017-08-02 11:14:05 +01:00
|
|
|
created_by=service.created_by,
|
|
|
|
|
key_type=key_type,
|
2017-08-02 15:35:56 +01:00
|
|
|
id=id_,
|
2017-08-02 11:14:05 +01:00
|
|
|
secret=uuid.uuid4()
|
|
|
|
|
)
|
|
|
|
|
db.session.add(api_key)
|
|
|
|
|
db.session.commit()
|
|
|
|
|
return api_key
|
2017-08-03 14:05:13 +01:00
|
|
|
|
|
|
|
|
|
2017-08-04 19:08:05 +01:00
|
|
|
def create_inbound_number(number, provider='mmg', active=True, service_id=None):
|
2017-08-03 14:05:13 +01:00
|
|
|
inbound_number = InboundNumber(
|
2017-08-04 19:19:43 +01:00
|
|
|
id=uuid.uuid4(),
|
|
|
|
|
number=number,
|
|
|
|
|
provider=provider,
|
|
|
|
|
active=active,
|
2017-08-03 14:05:13 +01:00
|
|
|
service_id=service_id
|
|
|
|
|
)
|
|
|
|
|
db.session.add(inbound_number)
|
|
|
|
|
db.session.commit()
|
|
|
|
|
return inbound_number
|
2017-08-10 16:37:30 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
def create_monthly_billing_entry(
|
|
|
|
|
service,
|
|
|
|
|
start_date,
|
|
|
|
|
end_date,
|
|
|
|
|
notification_type,
|
|
|
|
|
monthly_totals=[]
|
|
|
|
|
):
|
|
|
|
|
entry = MonthlyBilling(
|
|
|
|
|
service_id=service.id,
|
|
|
|
|
notification_type=notification_type,
|
|
|
|
|
monthly_totals=monthly_totals,
|
|
|
|
|
start_date=start_date,
|
|
|
|
|
end_date=end_date
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
db.session.add(entry)
|
|
|
|
|
db.session.commit()
|
|
|
|
|
|
|
|
|
|
return entry
|