Notifications.serialize calls `Notifications.template.get_link`, so
we need TemplateHistory objects to generate their API URLs.
This generates a link to the `/v2/` version of the endpoint.
Refactor tests/db/create_service() to behave more like the real world.
Created new create_service_with_inbound_number and create_service_with_defined_sms_sender() test/db methods.
- had to update the serialization in the model so that the date time is appended with the UTC timezone
- test has been added to ensure that the schema will validate the response correctly
International SMS is a mature, documented feature now. There’s no reason
it shouldn’t be available to everyone. If it’s turned off by default
then we’re relying on people finding it in the settings page to know
that it exists (which we found in research the other week that users,
who would have benefitted from having international SMS, were failing to
do).
This also fixes the problem whereby users signing up for Notify with an
international phone number (eg those working abroad for the Foreign and
Commonwealth Office) couldn’t get through the tour because they weren’t
able to send themselves the example text message (see
https://www.pivotaltracker.com/story/show/150705515).
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
In the future, we may want to return additional information about
placeholders.
We came up with three possible formats:
1. list of `dict`s, eg `[{'name': 'first name', 'required': True}]`
2. `dict` of `list`s, eg `{'required': ['first name']}`
3. `dict` of `dict`s, eg `{'name': {'required': True}}`
I don’t like 1. because it’s harder to traverse if all you want is the
name of the placeholders, and suggests that you could have two
placeholders with the same name (which you can’t). I don’t like 2.
because it only lets the data be sliced by one dimension (unless the
inner lists aren’t exclusive, in which case you’d need to filter
duplicates when just listing placeholders).
I think 3. has the two advantages of:
- represents that personalisation is unique, ie you can’t pass back in
two different values for the same key
- is forward compatible, ie we can add many more properties of a
placeholder without breaking anything
So this commit implements 3.
> Currently when retrieving a template via one of the clients, we do
> not return the personalisation fields that are required for that
> template.
>
> This is useful for services who want to perform template validation on
> their own systems. A service user has also requested this.
– https://www.pivotaltracker.com/story/show/150674476
This commit adds an extra attribute to the JSON response containing an
array of the placeholder names. This key is called "personalisation",
to match the argument that developers use to pass in the values of
placeholders.
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.
The use for the public template API is for building caseworking systems
or similar, where you might need a list of templates to pick from (ie
instead of using the Notify web interface to pick from and send a
message).
Right now our API isn’t returning the template name as part of the
response. The name is a useful, human-friendly way of identifying a
template.
This commit changes the response to include the name.
Some clients will need updating before this can be useful.
