We only need one rate per channel. This reflects that. The provider_rates has been left for now, it is still not being used.
New dao has been added to select the right rate for the given notification_type and date of notificaiton.
ready to send == we have created a dvla file in S3, the job id is in the file name
sent to dvla == we have created an aggregate dvla file to send for the day and have sent the file via sftp
when we change the last logged in time, set the current session id to
a random uuid
this way, we can compare it to the cookie a user has, and if they
differ then we can log them out
also update user.logged_in_at at 2FA rather than password check, since
that feels more accurate
If the template is marked as priority the notification will be sent using the `notify` queue.
The `notify` queue is a low volume queue, messages here will not be queue behind a large job and should be delivered with in a more consistent time frame.
- Added templates.process_type and templates_history.process_type column.
- Added a template_process_type table to handle the enum for templates.process_type, initial values are normal and priority
https://www.pivotaltracker.com/story/show/135429147
set all existing rows to have a version of 1 (also copy across values
to populate the new provider_details_history table in the upgrade
script)
in dao_update_provider_details bump the provider_details.version by 1
and then duplicate into the history table as a new row
(done manually as opposed to the decorator used in template_history
since this is only edited in this one place and the decorator is icky)
* to be used for auditing changes to provider details
* not hooked in yet
* also made provider_details.active non-nullable. set all existing null
provider_details.active to FALSE. none are set false on live so
should hopefully be fairly uncontroversial
* refactored NotificationHistory.from_notification and update from noti
to share with provider_details_history
Two different versions of 0059 were merged.
`0059_set_services_to_active` was merged first, so this renames my
migration to `0060`, so it goes in afterwards.
A letter type was added to the `enum` in the `Template` model at the
same it was added to the `Notification` model. But the migration was
only done for the `notifications` table, not the `templates` table.
See: https://github.com/alphagov/notifications-api/commit/25db1bce#diff-516aab258e161fc65e7564dabd2c625aR19
This commit does the migration to add `letter` as a possible value for
the `template_type` column, which is a bit fiddly because `enum`s.
Before:
```
notification_api=# select enum_range(null::template_type);
enum_range
-------------
{sms,email}
(1 row)
```
After upgrade:
```
notification_api=# select enum_range(null::template_type);
enum_range
--------------------
{sms,email,letter}
(1 row)
```
After downgrade
```
notification_api=# select enum_range(null::template_type);
enum_range
-------------
{sms,email}
(1 row)
```
services can have a whitelist of phone numbers and email addresses that they
can send to in addition to team members when in trial mode. email_address
and mobile_number are nullable and app level checks will be in place to
prevent inserting blank rows. they have a created_at date so that we can
[potentially] delete them a week later to avoid keeping personally identifying
data any longer than necessary
The cancelled job migration originally went in as version `0051`.
But `0051_set_job_status` went in first in
e3fa8bffd7
This meant that Alembic couldn’t work out what order to run the
migrations in, and blew up.
This commit puts the scheduled job migration after all others.
If you schedule a job you might change your mind or circumstances might
change. So you need to be able to cancel it. This commit adds a `POST`
endpoint for individual jobs which sets their status to `cancelled`.
This also means adding a new status of `cancelled`, so there’s a
migration…
