The personalisation for letters can take different formats depending on
how the letter was generated, for example it can contain either
address_line_1 or addressline1. This change ensures that it is always
serialized in the same way.
PR #1550 added the rate_limit column to the Service table.
This PR removes the rate limits from the config and uses rate_limit from
the Service model instead. Rate limits are still separated into 'team',
'normal' and 'test', but these values are the same for a service.
Pivotal story https://www.pivotaltracker.com/story/show/153992529
If is_letter_contact_blank then the user has set the letter contact block to be blank on purpose
ELSE IF is_letter_contact_blank is false THEN use the template default
IF template default is blank THEN the service_letter_contact is blank use the service default
Returns either template's reply_to text if set or the related field
from the default service record.
Return value can be used as default for `Notification.reply_to_text`
when per-notification value is not provided.
- Added has_permission helper in models.py to check permission in service
- Moved letters pdf tasks to separate file
- Moved letters pdf tests to own file
* remove from model
* still required when calling POST /service - we just call through
from dao_create_service to add a new annual billing entry.
* removed from POST /service/<id> update_service - if you want to
update/add a new one, use POST /service/<id>/free-sms-fragment-limit
* made sure tests create services with default 250k limit.
- Added the boolean 'crown' column to services and services_history tables
- We populate this column in the same migration script by checking the
'organisation_type' of a service
reply_to requires template_type to be already set, but the order
of attribute assignment is not defined when a model object is created
from a dictionary.
This adds a constructor to Template model that makes sure that
template_type is set first when multiple arguments are passed to the
constructor at once.
The problem might still exist when the template is created through the
API, so this is a temporary fix to unblock the release.
Adds a relationship between Template models and service letter contact
blocks.
Depending on template type, we can have a reference to either a letter
contact block, email reply-to address or SMS sender record. This means
that in order to enforce foreign key constraints we need to define three
separate foreign key columns on the template model.
To hide this implementation detail and make it easier to access the
sender/reply-to information we define a wrapper property that returns
the value from the correct column.
The relationship and the property are only defined for letter templates
at the moment.
The setter raises an error when trying to assign a reply_to value for
non-letter templates. The exception isn't raised if the value being
assigned is `None` since it can get assigned by marshmallow schemas
and as it matches the value returned for other template types it
doesn't need to be written anywhere.
This allows us to avoid duplication between Template and TemplateHistory
classes and makes it easier to ensure that all columns are copied
to the TemplateHistory objects.
Added a new endpoint which combines the usage of the stats table and the
data from the notifications tables, instead of using all the data from
the notification_history table. This should speed up the query times
and improve the page performance.
- Updated to make the stats create and update function transactional as
it actually wasn't committing the data to the table
- Added the get from the stats table
- Add a a method to combine the two results
- Added the endpoint
Relationship attribute is not used by the application code, so we
can remove it without replacing it with a TemplateHistory one.
This also updates the foreign key constraint to refer to the composite
primary key for the TemplateHistory records.
TemplateHistory objects need to be connected to the template's
TemplateRedacted record. This requires setting up a new SQLAlchemy
relationship to allow accessing redact_personalisation from
TemplateHistory instances.
We can avoid creating a foreign key in this case by setting up an
explicit `primaryjoin` expression. Since TemplateHistory.id is
created from Template.id and TemplateRedacted.template_id is
already a foreign key to Template.id the foreign key should always
be valid even without a DB constraint.
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.
Each notification instance is connected to a specific version of the
template that was used to generate notification content. Template
versions are stored in TemplateHistory, so that's the table we need
to use for Notifications.template relationship.
Currently, using Notifications.template returns the latest template
version, which leads to incorrect content being returned by the API
if the template has been updated.
This change removes Notifications.template_history attribute and
replaces template relationship to refer to TemplateHistory instance
based on the notification's template ID and version.
Currently the 'See templates used by month' report is timing out for
some services due to the query time of the data from notification_history
This is a stats table which will hold the data and will be updated by a
scheduled celery task once a day. This data will be combined with the
'live' data from notifications tables (which will be considerably less)
to form the data of the new report.
