> 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.
Add new endpoint to allocate a specific number to a given service.
This will allow the platform admin user to choose a number when setting the inbound_sms permission for a service.
Code was not expecting logo to be `None`, thereby causing the task to
throw an exception, and retry until eventually putting the email in
technical error (for services with org branding but no logo).
previously they were using sample_service fixture under the hood, but
with full permissions added - this works fine, **unless** there's
already a service with the name "sample service" in the database. This
can happen for two reasons:
* A previous test didn't tear down correctly
* This test already invoked the sample_service fixture somehow
If this happens, we just return the existing service, without modifying
its values - values that we might change in tests, such as
research mode or letters permissions.
In the future, we'll have to be vigilant! and aware! and careful! to
not use sample_service if we're doing tests involving letters, since
they create a service with a different name now
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
created and sending aren't quite as helpful for letters, since their
journey through notify and our providers is so different to emails/sms.
So instead, we should return estimated_dispatch_date (in a future PR)
and the status should just read received_by_notify
Added an extra name, 'org_banner', for branding types into branding_type table
Added org banner into user model in database
Added checks for new branding type to ensure that the correct data is passed into the dict
Tested new checks in html email options
