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.
so they can be distinguished on the frontend.
Also, some related cleanup:
* don't show test api letters on the frontpage
* make sure the subject is returned from the API for letters
* make sure the letter's address is returned for letters
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
there are three steps to this
1. Create a job
* Starts in status 'ready to send'
* Created by None, since it's from the API
* original file name 'letter submitted via api'
2. Create a single notification for that job
* job_row_number 0
* client reference if provided
* address line 1 as recipient
3. Trigger the build_dvla_file task
we know that all the notifications have been created for this job
(since we just created them ourselves synchronously), so this will
just create the dvla-format file for the job, and upload it to s3.
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.
* Alter config so an error will be raised if you forget to mock out a
celery call in one of your tests
* Remove an unneeded exception type that was masking errors
currently, they're made by creating a one-line job, but we want to
reduce task/csv file noise so we're moving them to persist in the
same vein as API usage. However, we can't just call through to that
since there are some differences:
* no api keys
* tighter control over API format
* no scheduling
* no client references
etc.
So, re-using as much of the v2 validation stuff as possible, I've
created this file that just does basic validation, and then calls
through to persist_notification and schedules a task. Woo.
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.
- uses new utils methods to validate phone numbers
- defaults to International=True on validation. This ensures the validator works on all numbers
- Then check if the user can send this message to the number internationally if needed.
- both V1 and V2 APIs
- Rate limiting wrapped into a new method - check_rate_limiting
- delegates to the previous daily limit and the new though put limit
- Rate limiting done on key type. Each key has it's own limit (number of requests) and interval (time period of requests)
- Configured in the config. Not done on a per-env basis though could be in the future.
