Added clarification to an error message to give better debugging information.
Removed using dao_get_reply_to_by_service_id in tests to be more consistent with other code and use the test db functions or remove the need for a call altogether making the code less complex.
* Added service_email_reply_to_id to the POST /v2/notifications/email and a test to test the validator
* Caught NoResultFound exception in check_service_email_reply_to_id as it was not being caught when there there was no valid service_id or reply_to_id. Fixed failing tests which were not passing due to the NoResultFound exception and added further tests to check for the good path through the code and an test to check for an invalid service_id
* Added service_email_reply_to_id to the POST /v2/notifications/email and a test to test the validator
* Caught NoResultFound exception in check_service_email_reply_to_id as it was not being caught when there there was no valid service_id or reply_to_id. Fixed failing tests which were not passing due to the NoResultFound exception and added further tests to check for the good path through the code and an test to check for an invalid service_id
* Fixed code style in validators.py to confirm with rules
Update the name of email_reply_to_id to conform better with other attributes in the schema and the resultant code in post_notifications.py
Fixed code style in test_validators.py to confirm with rules
Added tests to test_post_notifications.py to test the email_reply_to_id being present and being incorrect, it being optional is being tested by other tests.
* Added service_email_reply_to_id to the POST /v2/notifications/email and a test to test the validator
* Added service_email_reply_to_id to the POST /v2/notifications/email and a test to test the validator
* Caught NoResultFound exception in check_service_email_reply_to_id as it was not being caught when there there was no valid service_id or reply_to_id. Fixed failing tests which were not passing due to the NoResultFound exception and added further tests to check for the good path through the code and an test to check for an invalid service_id
* Caught NoResultFound exception in check_service_email_reply_to_id as it was not being caught when there there was no valid service_id or reply_to_id. Fixed failing tests which were not passing due to the NoResultFound exception and added further tests to check for the good path through the code and an test to check for an invalid service_id
* Fixed code style in validators.py to confirm with rules
Update the name of email_reply_to_id to conform better with other attributes in the schema and the resultant code in post_notifications.py
Fixed code style in test_validators.py to confirm with rules
Added tests to test_post_notifications.py to test the email_reply_to_id being present and being incorrect, it being optional is being tested by other tests.
* Minor update after manual merge to fix check style rule break in test_validators.py where a single space was introduced.
* Updates after code review. Moved the template from the exception message as it was not required and updated the error message to match the field name in the sschema for better debugging and error identification.
* Fixed test after update of exception message
this gets tests passing for now, but we'll need to make sure that
notifications.serialize handles letters with personalisation that
doesn't include underscores in future - for example, address_line_1
may also be addressline1 if someone uploaded a CSV
> For get all or get one letter the response needs to be updated so that
> it looks similar to admin app.
>
> status: created|sending --> received letter
> new column: `estimated delivery date`: derived from created at date.
> (see how the admin app is doing it)
>
> NOTE:
> At the moment we only have 2 statuses for a letter created and
> sending, but we will want to have other internal statuses that make
> sense to the Notify team but not our services. When we know those
> statuses the status map will be updated at that point.
– https://www.pivotaltracker.com/story/show/150512525
This commit implements the date (not status) part of this story.
My local build was not always getting the optional requirement for the jsonschema uri format checker (rfc3987).
The requirement has been added to the requirements_for_test file.
I changed the tests to validate the response schema from the post_notifications tests, this way we can tell if we are breaking the contract.
This showed that the email_from was not returning the entire email address but just the username, that has been corrected here.
Removed the response schema validation tests since they are not being testing in the post notification tests.
Removed the tests for trial mode service for the scheduled tasks and the process job.
Having the validation in the POST notification and create job endpoint is enough.
Updated the test_service_whitelist test because the order of the array is not gaurenteed.
when in research mode or test key, dont send letters via api - instead,
just put them straight to success state
when using a team key, flat out reject the request (403)
Since letter jobs from the API aren't created by any single individual,
lets make created_by nullable. Note: We'll have to make sure that we
update the admin app to handle these jobs nicely
when functions get as big as that, it's confusing to try and work out what
things are what. By including a * as the first arg, we require that anyone
calling the function has to use kwargs to reference the parameters
similar to sms/email, however, for consistency with response values
and internal storage, rather than supplying an "email_address" field
or a "phone_number" field, supply an "address_line_1" and "postcode"
field within the personalisation object.
Added a validation method that always fails for scheduled notifications.
Comment out config for scheduled task.
The schedule notifications will be turned on once we can invite services to use it.
Waiting for the service permission story, must commit this in order to keep things from going stale.
this means that on non-prod envs, it reflects that environment.
it needs to be a lamdba, because the column object is created at import
time, when current_app.config won't have been loaded - this means that
when you create a Service object, that lambda executes and grabs the
correct default value
jsonschema states:
> A format attribute can generally only validate a given set of
> instance types. If the type of the instance to validate is not in
> this set, validation for this format attribute and instance SHOULD
> succeed.
We were not checking for the type of the input, and our validators were
behaving in unexpected manners (throwing TypeErrors etc etc). Despite
us declaring that the phone_number field is of type `str`, we still
need to make sure the validator passes gracefully, so that the inbuilt
type check can be the bit that catches if someone passes in a non-str
value. We've seen this with people passing in integers instead of strs
for phone numbers. This'll make them receive a nice 400 error
(e.g. "phone_number 12345 is not of type string"), rather than us
having a 500 internal server error
