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
|
|
|
import uuid
|
2018-09-18 15:22:08 +01:00
|
|
|
from datetime import datetime, date
|
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-10-06 17:08:06 +01:00
|
|
|
from app import db
|
2018-09-18 15:22:08 +01:00
|
|
|
from app.dao.email_branding_dao import dao_create_email_branding
|
|
|
|
|
from app.dao.inbound_sms_dao import dao_create_inbound_sms
|
|
|
|
|
from app.dao.invited_org_user_dao import save_invited_org_user
|
2018-09-17 15:45:29 +01:00
|
|
|
from app.dao.invited_user_dao import save_invited_user
|
2017-03-15 15:26:58 +00:00
|
|
|
from app.dao.jobs_dao import dao_create_job
|
2018-09-18 15:22:08 +01:00
|
|
|
from app.dao.notifications_dao import (
|
|
|
|
|
dao_create_notification,
|
|
|
|
|
dao_created_scheduled_notification
|
|
|
|
|
)
|
|
|
|
|
from app.dao.organisation_dao import dao_create_organisation
|
|
|
|
|
from app.dao.service_callback_api_dao import save_service_callback_api
|
2018-07-11 17:02:49 +01:00
|
|
|
from app.dao.service_data_retention_dao import insert_service_data_retention
|
2017-06-15 11:32:51 +01:00
|
|
|
from app.dao.service_inbound_api_dao import save_service_inbound_api
|
2018-09-18 15:22:08 +01:00
|
|
|
from app.dao.service_permissions_dao import dao_add_service_permission
|
2017-11-07 14:26:18 +00:00
|
|
|
from app.dao.service_sms_sender_dao import update_existing_sms_sender_with_inbound_number, dao_update_service_sms_sender
|
2018-12-31 14:34:02 +00:00
|
|
|
from app.dao.services_dao import dao_create_service, dao_add_user_to_service
|
2018-11-08 16:44:57 +00:00
|
|
|
from app.dao.templates_dao import dao_create_template, dao_update_template
|
2018-09-18 15:22:08 +01:00
|
|
|
from app.dao.users_dao import save_model_user
|
2017-05-24 14:24:57 +01:00
|
|
|
from app.models import (
|
2017-08-02 11:14:05 +01:00
|
|
|
ApiKey,
|
2018-02-19 14:00:33 +00:00
|
|
|
DailySortedLetter,
|
2017-10-06 17:08:06 +01:00
|
|
|
InboundSms,
|
|
|
|
|
InboundNumber,
|
|
|
|
|
Job,
|
2017-05-24 14:24:57 +01:00
|
|
|
Notification,
|
2018-02-05 12:02:35 +00:00
|
|
|
EmailBranding,
|
2018-02-07 14:43:09 +00:00
|
|
|
Organisation,
|
2017-10-06 17:08:06 +01:00
|
|
|
Rate,
|
|
|
|
|
Service,
|
|
|
|
|
ServiceEmailReplyTo,
|
|
|
|
|
ServiceInboundApi,
|
2017-11-29 15:58:11 +00:00
|
|
|
ServiceCallbackApi,
|
2017-10-06 17:08:06 +01:00
|
|
|
ServiceLetterContact,
|
2017-05-24 14:24:57 +01:00
|
|
|
ScheduledNotification,
|
|
|
|
|
ServicePermission,
|
2017-10-06 17:08:06 +01:00
|
|
|
ServiceSmsSender,
|
|
|
|
|
Template,
|
|
|
|
|
User,
|
2017-08-16 12:27:42 +01:00
|
|
|
EMAIL_TYPE,
|
|
|
|
|
SMS_TYPE,
|
2017-11-02 12:19:17 +00:00
|
|
|
KEY_TYPE_NORMAL,
|
|
|
|
|
AnnualBilling,
|
2018-02-19 17:14:01 +00:00
|
|
|
InvitedOrganisationUser,
|
2018-06-05 14:25:24 +01:00
|
|
|
FactBilling,
|
2018-06-29 16:40:24 +01:00
|
|
|
FactNotificationStatus,
|
2018-07-11 17:02:49 +01:00
|
|
|
Complaint,
|
2018-10-30 16:26:25 +00:00
|
|
|
InvitedUser,
|
|
|
|
|
TemplateFolder,
|
2017-10-06 17:08:06 +01:00
|
|
|
)
|
2016-12-28 12:30:21 +00:00
|
|
|
|
|
|
|
|
|
2018-02-23 13:30:35 +00:00
|
|
|
def create_user(mobile_number="+447700900986", email="notify@digital.cabinet-office.gov.uk", state='active', id_=None):
|
2016-12-28 12:30:21 +00:00
|
|
|
data = {
|
2018-02-23 13:30:35 +00:00
|
|
|
'id': id_ or 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(
|
2018-04-24 17:37:04 +01:00
|
|
|
user=None,
|
|
|
|
|
service_name="Sample service",
|
|
|
|
|
service_id=None,
|
|
|
|
|
restricted=False,
|
|
|
|
|
service_permissions=[EMAIL_TYPE, SMS_TYPE],
|
|
|
|
|
research_mode=False,
|
|
|
|
|
active=True,
|
|
|
|
|
email_from=None,
|
|
|
|
|
prefix_sms=True,
|
|
|
|
|
message_limit=1000,
|
2018-08-22 12:59:06 +01:00
|
|
|
organisation_type='central',
|
2019-01-02 17:15:27 +00:00
|
|
|
postage='second',
|
|
|
|
|
check_if_service_exists=False
|
2017-05-22 11:26:47 +01:00
|
|
|
):
|
2019-01-02 17:15:27 +00:00
|
|
|
if check_if_service_exists:
|
|
|
|
|
service = Service.query.filter_by(name=service_name).first()
|
|
|
|
|
if (not check_if_service_exists) or (check_if_service_exists and not service):
|
2018-12-31 13:01:24 +00:00
|
|
|
service = Service(
|
|
|
|
|
name=service_name,
|
|
|
|
|
message_limit=message_limit,
|
|
|
|
|
restricted=restricted,
|
|
|
|
|
email_from=email_from if email_from else service_name.lower().replace(' ', '.'),
|
2018-12-31 14:18:52 +00:00
|
|
|
created_by=user if user else create_user(email='{}@digital.cabinet-office.gov.uk'.format(uuid.uuid4())),
|
2018-12-31 13:01:24 +00:00
|
|
|
prefix_sms=prefix_sms,
|
|
|
|
|
organisation_type=organisation_type,
|
|
|
|
|
postage=postage
|
|
|
|
|
)
|
|
|
|
|
dao_create_service(service, service.created_by, service_id, service_permissions=service_permissions)
|
2017-08-23 11:09:54 +01:00
|
|
|
|
2018-12-31 13:01:24 +00:00
|
|
|
service.active = active
|
|
|
|
|
service.research_mode = research_mode
|
2018-12-31 14:34:02 +00:00
|
|
|
else:
|
2018-12-31 15:16:00 +00:00
|
|
|
if user and user not in service.users:
|
2018-12-31 14:34:02 +00:00
|
|
|
dao_add_user_to_service(service, user)
|
2017-11-07 14:26:18 +00:00
|
|
|
|
|
|
|
|
return service
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def create_service_with_inbound_number(
|
2018-04-24 17:37:04 +01:00
|
|
|
inbound_number='1234567',
|
|
|
|
|
*args, **kwargs
|
2017-11-07 14:26:18 +00:00
|
|
|
):
|
2017-11-15 11:00:56 +00:00
|
|
|
service = create_service(*args, **kwargs)
|
2017-07-31 18:28:00 +01:00
|
|
|
|
2017-11-07 14:26:18 +00:00
|
|
|
sms_sender = ServiceSmsSender.query.filter_by(service_id=service.id).first()
|
|
|
|
|
inbound = create_inbound_number(number=inbound_number, service_id=service.id)
|
|
|
|
|
update_existing_sms_sender_with_inbound_number(service_sms_sender=sms_sender,
|
|
|
|
|
sms_sender=inbound_number,
|
|
|
|
|
inbound_number_id=inbound.id)
|
|
|
|
|
|
|
|
|
|
return service
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def create_service_with_defined_sms_sender(
|
2018-04-24 17:37:04 +01:00
|
|
|
sms_sender_value='1234567',
|
|
|
|
|
*args, **kwargs
|
2017-11-07 14:26:18 +00:00
|
|
|
):
|
2017-11-15 11:04:33 +00:00
|
|
|
service = create_service(*args, **kwargs)
|
2017-11-07 14:26:18 +00:00
|
|
|
|
|
|
|
|
sms_sender = ServiceSmsSender.query.filter_by(service_id=service.id).first()
|
2017-11-15 11:04:33 +00:00
|
|
|
dao_update_service_sms_sender(service_id=service.id,
|
2017-11-07 14:26:18 +00:00
|
|
|
service_sms_sender_id=sms_sender.id,
|
|
|
|
|
is_default=True,
|
|
|
|
|
sms_sender=sms_sender_value)
|
|
|
|
|
|
2017-02-16 11:55:52 +00:00
|
|
|
return service
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def create_template(
|
2018-04-24 17:37:04 +01:00
|
|
|
service,
|
|
|
|
|
template_type=SMS_TYPE,
|
|
|
|
|
template_name=None,
|
|
|
|
|
subject='Template subject',
|
|
|
|
|
content='Dear Sir/Madam, Hello. Yours Truly, The Government.',
|
|
|
|
|
reply_to=None,
|
2018-11-08 16:44:57 +00:00
|
|
|
hidden=False,
|
|
|
|
|
archived=False,
|
|
|
|
|
folder=None,
|
2018-12-17 10:03:54 +00:00
|
|
|
postage=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 = {
|
List templates in alphabetical order
Currently templates are ordered by the newest created first. This made
sense when, after creating a new template, you were landed on the page
that listed all the templates. In other words, you needed to see
confirmation of the thing that you’ve just done.
Now (since https://github.com/alphagov/notifications-admin/pull/1195)
you get landed on the page for just that template. So you always see
the template you’ve just created, no matter how the list of templates is
ordered. So we are free to change the order of the templates.
Ordering by time created is not great, because it gives users no control
over which templates appear first. For example, our research reported
this from one team:
> One frustration they have is that when you add a new template it
> automatically goes to the top of the list. To get round this, whenever
> they add a new template they delete all of the existing ones and start
> again because they want to keep their templates in numerical order.
> They'd like to be able to control the order of templates in the list.
We _could_ give people some sort of drag-and-drop template ordering
thing. But this feels like overkill. I think that alphabetical order is
better because:
- it’s easily discoverable – anyone who wants to know how a list is
ordered can quickly tell just by looking at it
- it’s universal – everyone knows how alphabetical ordering works
- it’s familiar – this is how people documents on their computer are
ordered; there’s no new UI to learn
- it’s what users are doing already – from the same service as above:
> They number their templates 1,2a, 2b, 3a etc
So this commit changes the ordering from newest created first to
alphabetical.
Previous changes to template order and navigation:
- https://github.com/alphagov/notifications-admin/pull/1163
- https://github.com/alphagov/notifications-admin/pull/1195
- https://github.com/alphagov/notifications-admin/pull/1330
Implementation notes
---
I refactored some of the tests here. I still don’t think they’re great
tests, but they’re a little more Pythonic now at least.
I also added a sort by template type, so that the order is deterministic
when you have, for example, an email template and a text message
template with the same name. If you have two text message templates with
the same name you’re on your own.
2017-11-23 11:37:35 +00:00
|
|
|
'name': template_name or '{} Template Name'.format(template_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
|
|
|
'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,
|
2017-12-15 17:08:01 +00:00
|
|
|
'reply_to': reply_to,
|
2018-11-08 16:44:57 +00:00
|
|
|
'hidden': hidden,
|
|
|
|
|
'folder': folder,
|
2018-12-17 10:03:54 +00:00
|
|
|
'postage': postage,
|
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 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)
|
2018-11-08 16:44:57 +00:00
|
|
|
|
|
|
|
|
if archived:
|
|
|
|
|
template.archived = archived
|
|
|
|
|
dao_update_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(
|
2018-12-12 12:57:04 +00:00
|
|
|
template=None,
|
2018-04-24 17:37:04 +01:00
|
|
|
job=None,
|
|
|
|
|
job_row_number=None,
|
|
|
|
|
to_field=None,
|
|
|
|
|
status='created',
|
|
|
|
|
reference=None,
|
|
|
|
|
created_at=None,
|
|
|
|
|
sent_at=None,
|
|
|
|
|
updated_at=None,
|
|
|
|
|
billable_units=1,
|
|
|
|
|
personalisation=None,
|
|
|
|
|
api_key=None,
|
|
|
|
|
key_type=KEY_TYPE_NORMAL,
|
|
|
|
|
sent_by=None,
|
|
|
|
|
client_reference=None,
|
|
|
|
|
rate_multiplier=None,
|
|
|
|
|
international=False,
|
|
|
|
|
phone_prefix=None,
|
|
|
|
|
scheduled_for=None,
|
|
|
|
|
normalised_to=None,
|
|
|
|
|
one_off=False,
|
|
|
|
|
sms_sender_id=None,
|
2018-07-18 10:54:20 +01:00
|
|
|
reply_to_text=None,
|
2018-09-19 10:49:11 +01:00
|
|
|
created_by_id=None,
|
|
|
|
|
postage=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
|
|
|
):
|
2018-12-12 12:57:04 +00:00
|
|
|
assert job or template
|
|
|
|
|
if job:
|
|
|
|
|
template = job.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
|
|
|
if created_at is None:
|
|
|
|
|
created_at = datetime.utcnow()
|
2017-02-24 13:39:58 +00:00
|
|
|
|
2017-10-16 17:29:45 +01:00
|
|
|
if to_field is None:
|
|
|
|
|
to_field = '+447700900855' if template.template_type == SMS_TYPE else 'test@example.com'
|
|
|
|
|
|
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
|
|
|
|
2018-09-19 10:49:11 +01:00
|
|
|
if template.template_type == 'letter' and postage is None:
|
|
|
|
|
postage = 'second'
|
|
|
|
|
|
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-11-09 14:31:31 +00:00
|
|
|
'template_id': 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_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,
|
2017-11-27 15:24:16 +00:00
|
|
|
'normalised_to': normalised_to,
|
2018-07-18 10:54:20 +01:00
|
|
|
'reply_to_text': reply_to_text,
|
2018-09-19 10:49:11 +01:00
|
|
|
'created_by_id': created_by_id,
|
|
|
|
|
'postage': postage
|
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)
|
2017-11-29 16:47:23 +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
|
|
|
return notification
|
2017-03-15 15:26:58 +00:00
|
|
|
|
|
|
|
|
|
2017-06-02 12:21:12 +01:00
|
|
|
def create_job(
|
2018-04-24 17:37:04 +01:00
|
|
|
template,
|
|
|
|
|
notification_count=1,
|
|
|
|
|
created_at=None,
|
|
|
|
|
job_status='pending',
|
|
|
|
|
scheduled_for=None,
|
|
|
|
|
processing_started=None,
|
2018-11-26 16:30:23 +00:00
|
|
|
original_file_name='some.csv',
|
|
|
|
|
archived=False
|
2017-06-02 12:21:12 +01:00
|
|
|
):
|
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,
|
2018-11-26 16:30:23 +00:00
|
|
|
'processing_started': processing_started,
|
|
|
|
|
'archived': archived
|
2017-03-15 15:26:58 +00:00
|
|
|
}
|
|
|
|
|
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(
|
2018-04-24 17:37:04 +01:00
|
|
|
service,
|
|
|
|
|
notify_number=None,
|
|
|
|
|
user_number='447700900111',
|
|
|
|
|
provider_date=None,
|
|
|
|
|
provider_reference=None,
|
|
|
|
|
content='Hello',
|
|
|
|
|
provider="mmg",
|
|
|
|
|
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-11-07 14:26:18 +00:00
|
|
|
notify_number=notify_number or service.get_default_sms_sender(),
|
2017-05-31 14:49:14 +01:00
|
|
|
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(
|
2018-04-24 17:37:04 +01:00
|
|
|
service,
|
|
|
|
|
url="https://something.com",
|
|
|
|
|
bearer_token="some_super_secret",
|
2017-06-15 11:32:51 +01:00
|
|
|
):
|
|
|
|
|
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-11-29 15:58:11 +00:00
|
|
|
def create_service_callback_api(
|
2018-04-24 17:37:04 +01:00
|
|
|
service,
|
|
|
|
|
url="https://something.com",
|
|
|
|
|
bearer_token="some_super_secret",
|
2018-07-18 10:14:32 +01:00
|
|
|
callback_type="delivery_status"
|
2017-11-29 15:58:11 +00:00
|
|
|
):
|
|
|
|
|
service_callback_api = ServiceCallbackApi(service_id=service.id,
|
2017-11-30 09:38:57 +00:00
|
|
|
url=url,
|
|
|
|
|
bearer_token=bearer_token,
|
2018-07-18 10:14:32 +01:00
|
|
|
updated_by_id=service.users[0].id,
|
|
|
|
|
callback_type=callback_type
|
2017-11-30 09:38:57 +00:00
|
|
|
)
|
2017-11-29 15:58:11 +00:00
|
|
|
save_service_callback_api(service_callback_api)
|
|
|
|
|
return service_callback_api
|
|
|
|
|
|
|
|
|
|
|
2018-07-30 13:27:49 +01:00
|
|
|
def create_email_branding(colour='blue', logo='test_x2.png', name='test_org_1', text='DisplayName'):
|
2017-07-04 17:02:28 +01:00
|
|
|
data = {
|
|
|
|
|
'colour': colour,
|
|
|
|
|
'logo': logo,
|
2018-07-30 13:27:49 +01:00
|
|
|
'name': name,
|
|
|
|
|
'text': text,
|
2017-07-04 17:02:28 +01:00
|
|
|
}
|
2018-02-05 12:02:35 +00:00
|
|
|
email_branding = EmailBranding(**data)
|
|
|
|
|
dao_create_email_branding(email_branding)
|
2017-07-04 17:02:28 +01:00
|
|
|
|
2018-02-05 12:02:35 +00:00
|
|
|
return email_branding
|
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
|
|
|
|
|
|
|
|
|
2017-09-08 11:14:26 +01:00
|
|
|
def create_reply_to_email(
|
2018-06-05 17:23:24 +01:00
|
|
|
service,
|
|
|
|
|
email_address,
|
|
|
|
|
is_default=True,
|
|
|
|
|
archived=False
|
2017-09-08 11:14:26 +01:00
|
|
|
):
|
|
|
|
|
data = {
|
|
|
|
|
'service': service,
|
|
|
|
|
'email_address': email_address,
|
2017-09-13 15:27:00 +01:00
|
|
|
'is_default': is_default,
|
2018-04-25 12:19:12 +01:00
|
|
|
'archived': archived,
|
2017-09-08 11:14:26 +01:00
|
|
|
}
|
|
|
|
|
reply_to = ServiceEmailReplyTo(**data)
|
|
|
|
|
|
|
|
|
|
db.session.add(reply_to)
|
|
|
|
|
db.session.commit()
|
|
|
|
|
|
|
|
|
|
return reply_to
|
2017-09-21 16:08:49 +01:00
|
|
|
|
|
|
|
|
|
2017-09-21 16:41:10 +01:00
|
|
|
def create_service_sms_sender(
|
2018-06-05 17:23:24 +01:00
|
|
|
service,
|
|
|
|
|
sms_sender,
|
|
|
|
|
is_default=True,
|
|
|
|
|
inbound_number_id=None,
|
|
|
|
|
archived=False
|
2017-09-21 16:41:10 +01:00
|
|
|
):
|
|
|
|
|
data = {
|
|
|
|
|
'service_id': service.id,
|
|
|
|
|
'sms_sender': sms_sender,
|
|
|
|
|
'is_default': is_default,
|
2018-04-25 14:23:00 +01:00
|
|
|
'inbound_number_id': inbound_number_id,
|
|
|
|
|
'archived': archived,
|
2017-09-21 16:41:10 +01:00
|
|
|
}
|
|
|
|
|
service_sms_sender = ServiceSmsSender(**data)
|
|
|
|
|
|
|
|
|
|
db.session.add(service_sms_sender)
|
|
|
|
|
db.session.commit()
|
|
|
|
|
|
|
|
|
|
return service_sms_sender
|
|
|
|
|
|
|
|
|
|
|
2017-09-21 16:08:49 +01:00
|
|
|
def create_letter_contact(
|
2018-06-05 17:23:24 +01:00
|
|
|
service,
|
|
|
|
|
contact_block,
|
|
|
|
|
is_default=True,
|
|
|
|
|
archived=False
|
2017-09-21 16:08:49 +01:00
|
|
|
):
|
|
|
|
|
data = {
|
|
|
|
|
'service': service,
|
|
|
|
|
'contact_block': contact_block,
|
|
|
|
|
'is_default': is_default,
|
2018-04-25 12:33:10 +01:00
|
|
|
'archived': archived,
|
2017-09-21 16:08:49 +01:00
|
|
|
}
|
|
|
|
|
letter_content = ServiceLetterContact(**data)
|
|
|
|
|
|
|
|
|
|
db.session.add(letter_content)
|
|
|
|
|
db.session.commit()
|
|
|
|
|
|
|
|
|
|
return letter_content
|
2017-10-06 16:58:32 +01:00
|
|
|
|
|
|
|
|
|
2017-11-02 12:19:17 +00:00
|
|
|
def create_annual_billing(
|
2018-04-24 17:37:04 +01:00
|
|
|
service_id, free_sms_fragment_limit, financial_year_start
|
2017-11-02 12:19:17 +00:00
|
|
|
):
|
|
|
|
|
annual_billing = AnnualBilling(
|
|
|
|
|
service_id=service_id,
|
|
|
|
|
free_sms_fragment_limit=free_sms_fragment_limit,
|
|
|
|
|
financial_year_start=financial_year_start
|
|
|
|
|
)
|
|
|
|
|
db.session.add(annual_billing)
|
|
|
|
|
db.session.commit()
|
|
|
|
|
|
|
|
|
|
return annual_billing
|
2017-12-11 16:55:23 +00:00
|
|
|
|
|
|
|
|
|
2018-02-07 14:43:09 +00:00
|
|
|
def create_organisation(name='test_org_1', active=True):
|
|
|
|
|
data = {
|
|
|
|
|
'name': name,
|
|
|
|
|
'active': active
|
|
|
|
|
}
|
|
|
|
|
organisation = Organisation(**data)
|
|
|
|
|
dao_create_organisation(organisation)
|
|
|
|
|
|
|
|
|
|
return organisation
|
2018-02-19 17:14:01 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
def create_invited_org_user(organisation, invited_by, email_address='invite@example.com'):
|
|
|
|
|
invited_org_user = InvitedOrganisationUser(
|
|
|
|
|
email_address=email_address,
|
|
|
|
|
invited_by=invited_by,
|
|
|
|
|
organisation=organisation,
|
|
|
|
|
)
|
|
|
|
|
save_invited_org_user(invited_org_user)
|
|
|
|
|
return invited_org_user
|
2018-02-19 14:00:33 +00:00
|
|
|
|
|
|
|
|
|
2018-03-14 17:04:58 +00:00
|
|
|
def create_daily_sorted_letter(billing_day=date(2018, 1, 18),
|
|
|
|
|
file_name="Notify-20180118123.rs.txt",
|
|
|
|
|
unsorted_count=0,
|
|
|
|
|
sorted_count=0):
|
2018-02-19 14:00:33 +00:00
|
|
|
daily_sorted_letter = DailySortedLetter(
|
|
|
|
|
billing_day=billing_day,
|
2018-03-14 17:04:58 +00:00
|
|
|
file_name=file_name,
|
2018-02-19 14:00:33 +00:00
|
|
|
unsorted_count=unsorted_count,
|
|
|
|
|
sorted_count=sorted_count
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
db.session.add(daily_sorted_letter)
|
|
|
|
|
db.session.commit()
|
|
|
|
|
|
|
|
|
|
return daily_sorted_letter
|
2018-04-06 11:55:49 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
def create_ft_billing(bst_date,
|
|
|
|
|
notification_type,
|
2018-04-24 17:37:04 +01:00
|
|
|
template=None,
|
|
|
|
|
service=None,
|
2018-04-06 11:55:49 +01:00
|
|
|
provider='test',
|
|
|
|
|
rate_multiplier=1,
|
|
|
|
|
international=False,
|
|
|
|
|
rate=0,
|
|
|
|
|
billable_unit=1,
|
2018-09-26 11:28:59 +01:00
|
|
|
notifications_sent=1,
|
|
|
|
|
postage='none',
|
2018-04-06 11:55:49 +01:00
|
|
|
):
|
|
|
|
|
if not service:
|
|
|
|
|
service = create_service()
|
|
|
|
|
if not template:
|
|
|
|
|
template = create_template(service=service, template_type=notification_type)
|
|
|
|
|
|
|
|
|
|
data = FactBilling(bst_date=bst_date,
|
|
|
|
|
service_id=service.id,
|
|
|
|
|
template_id=template.id,
|
|
|
|
|
notification_type=notification_type,
|
|
|
|
|
provider=provider,
|
|
|
|
|
rate_multiplier=rate_multiplier,
|
|
|
|
|
international=international,
|
|
|
|
|
rate=rate,
|
|
|
|
|
billable_units=billable_unit,
|
2018-09-26 11:28:59 +01:00
|
|
|
notifications_sent=notifications_sent,
|
|
|
|
|
postage=postage)
|
2018-04-06 11:55:49 +01:00
|
|
|
db.session.add(data)
|
|
|
|
|
db.session.commit()
|
|
|
|
|
return data
|
2018-06-04 17:29:58 +01:00
|
|
|
|
|
|
|
|
|
2018-06-29 16:40:24 +01:00
|
|
|
def create_ft_notification_status(
|
|
|
|
|
bst_date,
|
2018-07-03 14:36:53 +01:00
|
|
|
notification_type='sms',
|
2018-06-29 16:40:24 +01:00
|
|
|
service=None,
|
|
|
|
|
template=None,
|
|
|
|
|
job=None,
|
|
|
|
|
key_type='normal',
|
|
|
|
|
notification_status='delivered',
|
|
|
|
|
count=1
|
|
|
|
|
):
|
2018-12-12 12:57:04 +00:00
|
|
|
if job:
|
|
|
|
|
template = job.template
|
2018-07-03 14:36:53 +01:00
|
|
|
if template:
|
|
|
|
|
service = template.service
|
|
|
|
|
notification_type = template.template_type
|
|
|
|
|
else:
|
|
|
|
|
if not service:
|
|
|
|
|
service = create_service()
|
2018-06-29 16:40:24 +01:00
|
|
|
template = create_template(service=service, template_type=notification_type)
|
|
|
|
|
|
|
|
|
|
data = FactNotificationStatus(
|
|
|
|
|
bst_date=bst_date,
|
|
|
|
|
template_id=template.id,
|
|
|
|
|
service_id=service.id,
|
|
|
|
|
job_id=job.id if job else uuid.UUID(int=0),
|
|
|
|
|
notification_type=notification_type,
|
|
|
|
|
key_type=key_type,
|
|
|
|
|
notification_status=notification_status,
|
|
|
|
|
notification_count=count
|
|
|
|
|
)
|
|
|
|
|
db.session.add(data)
|
|
|
|
|
db.session.commit()
|
|
|
|
|
return data
|
|
|
|
|
|
|
|
|
|
|
2018-06-05 14:25:24 +01:00
|
|
|
def create_complaint(service=None,
|
2018-06-07 16:01:41 +01:00
|
|
|
notification=None,
|
|
|
|
|
created_at=None):
|
2018-06-05 14:25:24 +01:00
|
|
|
if not service:
|
2018-06-05 17:23:24 +01:00
|
|
|
service = create_service()
|
2018-06-05 14:25:24 +01:00
|
|
|
if not notification:
|
|
|
|
|
template = create_template(service=service, template_type='email')
|
|
|
|
|
notification = create_notification(template=template)
|
|
|
|
|
|
|
|
|
|
complaint = Complaint(notification_id=notification.id,
|
2018-06-05 17:23:24 +01:00
|
|
|
service_id=service.id,
|
|
|
|
|
ses_feedback_id=str(uuid.uuid4()),
|
|
|
|
|
complaint_type='abuse',
|
2018-06-07 16:01:41 +01:00
|
|
|
complaint_date=datetime.utcnow(),
|
|
|
|
|
created_at=created_at if created_at else datetime.now()
|
2018-06-05 17:23:24 +01:00
|
|
|
)
|
2018-06-05 14:25:24 +01:00
|
|
|
db.session.add(complaint)
|
|
|
|
|
db.session.commit()
|
|
|
|
|
return complaint
|
|
|
|
|
|
|
|
|
|
|
2018-06-04 17:29:58 +01:00
|
|
|
def ses_complaint_callback_malformed_message_id():
|
2018-06-05 17:23:24 +01:00
|
|
|
return {
|
|
|
|
|
'Signature': 'bb',
|
|
|
|
|
'SignatureVersion': '1', 'MessageAttributes': {}, 'MessageId': '98c6e927-af5d-5f3b-9522-bab736f2cbde',
|
|
|
|
|
'UnsubscribeUrl': 'https://sns.eu-west-1.amazonaws.com',
|
|
|
|
|
'TopicArn': 'arn:ses_notifications', 'Type': 'Notification',
|
|
|
|
|
'Timestamp': '2018-06-05T14:00:15.952Z', 'Subject': None,
|
2018-06-06 10:37:31 +01:00
|
|
|
'Message': '{"notificationType":"Complaint","complaint":{"complainedRecipients":[{"emailAddress":"recipient1@example.com"}],"timestamp":"2018-06-05T13:59:58.000Z","feedbackId":"ses_feedback_id"},"mail":{"timestamp":"2018-06-05T14:00:15.950Z","source":"\\"Some Service\\" <someservicenotifications.service.gov.uk>","sourceArn":"arn:identity/notifications.service.gov.uk","sourceIp":"52.208.24.161","sendingAccountId":"888450439860","badMessageId":"ref1","destination":["recipient1@example.com"]}}', # noqa
|
2018-06-05 17:23:24 +01:00
|
|
|
'SigningCertUrl': 'https://sns.pem'
|
|
|
|
|
}
|
2018-06-04 17:29:58 +01:00
|
|
|
|
2018-06-06 10:37:31 +01:00
|
|
|
|
2018-06-04 17:29:58 +01:00
|
|
|
def ses_complaint_callback_with_missing_complaint_type():
|
|
|
|
|
"""
|
|
|
|
|
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/notification-contents.html#complaint-object
|
|
|
|
|
"""
|
2018-06-05 17:23:24 +01:00
|
|
|
return {
|
|
|
|
|
'Signature': 'bb',
|
|
|
|
|
'SignatureVersion': '1', 'MessageAttributes': {}, 'MessageId': '98c6e927-af5d-5f3b-9522-bab736f2cbde',
|
|
|
|
|
'UnsubscribeUrl': 'https://sns.eu-west-1.amazonaws.com',
|
|
|
|
|
'TopicArn': 'arn:ses_notifications', 'Type': 'Notification',
|
|
|
|
|
'Timestamp': '2018-06-05T14:00:15.952Z', 'Subject': None,
|
2018-06-06 10:37:31 +01:00
|
|
|
'Message': '{"notificationType":"Complaint","complaint":{"complainedRecipients":[{"emailAddress":"recipient1@example.com"}],"timestamp":"2018-06-05T13:59:58.000Z","feedbackId":"ses_feedback_id"},"mail":{"timestamp":"2018-06-05T14:00:15.950Z","source":"\\"Some Service\\" <someservicenotifications.service.gov.uk>","sourceArn":"arn:identity/notifications.service.gov.uk","sourceIp":"52.208.24.161","sendingAccountId":"888450439860","messageId":"ref1","destination":["recipient1@example.com"]}}', # noqa
|
2018-06-05 17:23:24 +01:00
|
|
|
'SigningCertUrl': 'https://sns.pem'
|
|
|
|
|
}
|
2018-06-04 17:29:58 +01:00
|
|
|
|
2018-06-06 10:37:31 +01:00
|
|
|
|
2018-06-04 17:29:58 +01:00
|
|
|
def ses_complaint_callback():
|
|
|
|
|
"""
|
|
|
|
|
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/notification-contents.html#complaint-object
|
|
|
|
|
"""
|
2018-06-05 17:23:24 +01:00
|
|
|
return {
|
|
|
|
|
'Signature': 'bb',
|
|
|
|
|
'SignatureVersion': '1', 'MessageAttributes': {}, 'MessageId': '98c6e927-af5d-5f3b-9522-bab736f2cbde',
|
|
|
|
|
'UnsubscribeUrl': 'https://sns.eu-west-1.amazonaws.com',
|
|
|
|
|
'TopicArn': 'arn:ses_notifications', 'Type': 'Notification',
|
|
|
|
|
'Timestamp': '2018-06-05T14:00:15.952Z', 'Subject': None,
|
2018-06-06 10:37:31 +01:00
|
|
|
'Message': '{"notificationType":"Complaint","complaint":{"complaintFeedbackType": "abuse", "complainedRecipients":[{"emailAddress":"recipient1@example.com"}],"timestamp":"2018-06-05T13:59:58.000Z","feedbackId":"ses_feedback_id"},"mail":{"timestamp":"2018-06-05T14:00:15.950Z","source":"\\"Some Service\\" <someservicenotifications.service.gov.uk>","sourceArn":"arn:identity/notifications.service.gov.uk","sourceIp":"52.208.24.161","sendingAccountId":"888450439860","messageId":"ref1","destination":["recipient1@example.com"]}}', # noqa
|
2018-06-05 17:23:24 +01:00
|
|
|
'SigningCertUrl': 'https://sns.pem'
|
|
|
|
|
}
|
2018-06-04 17:29:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
def ses_notification_callback():
|
|
|
|
|
return '{\n "Type" : "Notification",\n "MessageId" : "ref1",' \
|
|
|
|
|
'\n "TopicArn" : "arn:aws:sns:eu-west-1:123456789012:testing",' \
|
|
|
|
|
'\n "Message" : "{\\"notificationType\\":\\"Delivery\\",' \
|
|
|
|
|
'\\"mail\\":{\\"timestamp\\":\\"2016-03-14T12:35:25.909Z\\",' \
|
|
|
|
|
'\\"source\\":\\"test@test-domain.com\\",' \
|
|
|
|
|
'\\"sourceArn\\":\\"arn:aws:ses:eu-west-1:123456789012:identity/testing-notify\\",' \
|
|
|
|
|
'\\"sendingAccountId\\":\\"123456789012\\",' \
|
|
|
|
|
'\\"messageId\\":\\"ref1\\",' \
|
|
|
|
|
'\\"destination\\":[\\"testing@digital.cabinet-office.gov.uk\\"]},' \
|
|
|
|
|
'\\"delivery\\":{\\"timestamp\\":\\"2016-03-14T12:35:26.567Z\\",' \
|
|
|
|
|
'\\"processingTimeMillis\\":658,' \
|
|
|
|
|
'\\"recipients\\":[\\"testing@digital.cabinet-office.gov.uk\\"],' \
|
|
|
|
|
'\\"smtpResponse\\":\\"250 2.0.0 OK 1457958926 uo5si26480932wjc.221 - gsmtp\\",' \
|
|
|
|
|
'\\"reportingMTA\\":\\"a6-238.smtp-out.eu-west-1.amazonses.com\\"}}",' \
|
|
|
|
|
'\n "Timestamp" : "2016-03-14T12:35:26.665Z",\n "SignatureVersion" : "1",' \
|
|
|
|
|
'\n "Signature" : "X8d7eTAOZ6wlnrdVVPYanrAlsX0SMPfOzhoTEBnQqYkrNWTqQY91C0f3bxtPdUhUt' \
|
|
|
|
|
'OowyPAOkTQ4KnZuzphfhVb2p1MyVYMxNKcBFB05/qaCX99+92fjw4x9LeUOwyGwMv5F0Vkfi5qZCcEw69uVrhYL' \
|
|
|
|
|
'VSTFTrzi/yCtru+yFULMQ6UhbY09GwiP6hjxZMVr8aROQy5lLHglqQzOuSZ4KeD85JjifHdKzlx8jjQ+uj+FLzHXPMA' \
|
|
|
|
|
'PmPU1JK9kpoHZ1oPshAFgPDpphJe+HwcJ8ezmk+3AEUr3wWli3xF+49y8Z2anASSVp6YI2YP95UT8Rlh3qT3T+V9V8rbSVislxA==",' \
|
|
|
|
|
'\n "SigningCertURL" : "https://sns.eu-west-1.amazonaws.com/SimpleNotificationService-bb750' \
|
|
|
|
|
'dd426d95ee9390147a5624348ee.pem",' \
|
|
|
|
|
'\n "UnsubscribeURL" : "https://sns.eu-west-1.amazonaws.com/?Action=Unsubscribe&S' \
|
|
|
|
|
'subscriptionArn=arn:aws:sns:eu-west-1:302763885840:preview-emails:d6aad3ef-83d6-4cf3-a470-54e2e75916da"\n}'
|
2018-07-11 17:02:49 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
def create_service_data_retention(
|
|
|
|
|
service_id,
|
|
|
|
|
notification_type='sms',
|
|
|
|
|
days_of_retention=3
|
|
|
|
|
):
|
|
|
|
|
data_retention = insert_service_data_retention(
|
|
|
|
|
service_id=service_id,
|
|
|
|
|
notification_type=notification_type,
|
|
|
|
|
days_of_retention=days_of_retention
|
|
|
|
|
)
|
|
|
|
|
return data_retention
|
2018-09-17 15:45:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
def create_invited_user(service=None,
|
|
|
|
|
to_email_address=None):
|
|
|
|
|
|
|
|
|
|
if service is None:
|
|
|
|
|
service = create_service()
|
|
|
|
|
if to_email_address is None:
|
|
|
|
|
to_email_address = 'invited_user@digital.gov.uk'
|
|
|
|
|
|
|
|
|
|
from_user = service.users[0]
|
|
|
|
|
|
|
|
|
|
data = {
|
|
|
|
|
'service': service,
|
|
|
|
|
'email_address': to_email_address,
|
|
|
|
|
'from_user': from_user,
|
|
|
|
|
'permissions': 'send_messages,manage_service,manage_api_keys'
|
|
|
|
|
}
|
|
|
|
|
invited_user = InvitedUser(**data)
|
|
|
|
|
save_invited_user(invited_user)
|
|
|
|
|
return invited_user
|
2018-10-30 16:26:25 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
def create_template_folder(service, name='foo', parent=None):
|
|
|
|
|
tf = TemplateFolder(name=name, service=service, parent=parent)
|
|
|
|
|
db.session.add(tf)
|
|
|
|
|
db.session.commit()
|
|
|
|
|
return tf
|