The `serialize` method of the Notification model now includes the
`created_by_name`. If a notification was sent as a one-off message this
value will now be the name of the person who sent the notification. If
a notification was sent through the API or by a CSV upload we don't
record the id of the sender, so `created_by_name` will be `None`.
This change affects the data that gets returned from these endpoints:
* /v2/notifications/<notification_id>
* /v2/notifications
We want to add the option for a user to have a more restricted view of
Notify.
This should be opt in/out on a per service basis, because it will be
appropriate only for a minority of teams. It shouldn’t be the default
because most teams (those without a lot of users or those only using the
API) won’t need it.
So this commit adds it as a new service permission, which means we can
roll it out:
- in prototype form initially
- then as an opt-in service setting
This is going to be used for for the document download citizen landing
page, a service will add a contact link
e.g. https://customerservicecontactnumber.uk/dwp/ which will allow the
user to contact the sending department if there is an error or any
issues with the download.
* Added the contact link to the model
* Added db migration script to add the column to the database
If a someone gets an email from one of our services and then complain about it (mark as spam or otherwise), we get a callback from SES.
The service needs to know about these complaints so they can remove that email from their mailing list.
Added created_at and updated_at to the ft_notification_status table in order
to make it easier to track down any potential issues with the data.
Also updated the command to populate the data to take created_at and
updated_at into account and to simplify the command. This can all be done in
the same commit since the table is not being used anywhere yet and can
only be populated manually.
`created_at` was added previously and made nullable temporarily. This
commit now populates the column, ensures that it will always have a
value, and makes `created_at` non-nullable.
Added `created_at` and `updated_at` to the `ft_billing` table - having these
columns makes it easier to track down issues with the data in this table.
`created_at` is nullable initially, but will be changed to non-nullable
once the column is populated and the DAO etc. have been updated.
Update test_provider_statistics dao - this is really irrelevant since the endpoint using the query is not being used. We have a PR coming to delete the unused code.
Update rate_multiplier to always be an integer
This was because the rate_multiplier was being added as 1 and 1.0 which was not resolving to the same.
This updates the table to use Integrer.
Also changed the logging for the task.
Added a new boolean column, `archived`, with a default of False to the
three models which are used to specify the 'reply to' address for
notifications:
* ServiceEmailReplyTo
* ServiceSmsSender
* ServiceLetterContact
We need to deal with this, it's ok when updating a notification status from delivered to delivered. But the DailySortedLetter counts are being doubled.
Adding the file_name to the table as a unique key to get around this issue. It will mean we have multiple rows for each billing_day, but that's ok we can aggregate that.
This will also give us a way to see which file created which count.
contains orgs, and unmapped services.
the orgs contain nested services - services the user is a part of that
belong to that org.
the unmapped services are any services that the user is a part of that
either don't have an org or have one that the user doesn't know about
this is so that we can filter out inactive organisations and services
note: can't remove user schema completely, as we still use it in
POST /user to create new users
Added the following new notification statuses:
* pending_virus_check
* virus_scan_failed
If we decide to remove these statuses in future, we will need to replace
them with a different status in the notifications and
Notification_history tables where they are referenced, so
pending-virus-check will be replaced with sending, and virus-scan-failed
will be replaced with permanent-failure.
The response files we receive from the DVLA when we send letters
contain a row for each letter and a field with a value of 'Unsorted' or
'Sorted'. This table will be used to store the total number of
'Unsorted' and 'Sorted' letter notifications per day.
Postcodes are required for created letters, but not for precompiled, this fix allows postcodes to be None in the model.
As postcodes are still required for created letter they should be caught by validation schemas in the POST handler
Allows hiding templates from the templates list in the admin app
and related API responses.
This is used for 'internal' templates that we create for notifications
that wouldn't have a template otherwise (eg pre-compiled PDF letters)
