Sometimes a job finishes but has missed a row in the middle. It is a mystery why this is happening, it could be that the task to save the notifications has been dropped.
So until we solve the missing let's find missing rows and process them.
A new scheduled task has been added to find any "finished" jobs that do not have enough notifications created. If there are missing notifications the job processes those rows for the job.
Adding the new task to beat schedule will be done in the next commit.
A unique key constraint has been added to Notifications to ensure that the row is not added twice. Any index or constraint can affect performance, but this unique constraint should not affect it enough for us to notice.
Although their allowances are the same as what we call `nhs_local` it
makes more sense to store them separately because:
- we already present them as two separate choices to the user
- we may want to handle them differently in the future, eg in terms of
what branding choices are available to them
This table is no longer used or referenced in the code.
We can remove this mapping table now that the organisation to service relationship is handled by the foreign key in Services.
This is the second commit in the series to add organisation_id to Service.
- Data migration to update services.organisation_id from data in organisation_to_service
(The rollback will lose any updates to organisation unless the script is updated to set organistion_to_service from service.organisation_id )
- Update Service.organisation relationship to a ForeignKey relationship to Organisation.
- Update Organisation.services to a backref relationship to Service.
Because these were slightly different, the `check_if_new_migration`
script would always think there was a new migration to run and so we
were always testing the db migrations when deploying.
* tell the user that clicks the button
* tell the notify team
* tell the person that the button was clicked on behalf of
there are two templates for the first case
This is changing because we’re going to introduce accepting contracts
and MoUs online.
Previously
---
We had one column for who signed the agreement, which is foreign keyed
to the user table. This is still relevant, because there will always be
a user who is clicking the button.
Now
---
We add two new fields for the name and email address of the person on
whose behalf the agreement is being accepted. This person:
- is different from the one signing the agreement
- won’t necessarily have a Notify account
go_live_user_id: is the user that requested the service to go live
go_live_at: is the DateTime the service went live.
There will be a data migration from the beta partners spreadsheet to back fill the data.
This relationship is via the `Organisation` now; we don’t use this
column to fudge a relationship based on the user’s email address and the
matching something in these columns.
Needed to update old migration scripts so that the email_branding name is not null when creating the test dbs.
This should no affect the migrations elsewhere.
Currently when someone creates a service we match them to an
organisation. Then if the organisation has a default branding set, their
service gets that branding.
However none of the organisations yet have a default branding set up.
This commit migrates the data about the relationship between an
organisation and its branding from being inferred from the `domain`
field on the branding, to being a proper database relationship.
The previous migration didn’t work because the `created_by_id` column
in services references the user who created the _version_ of the
service, not who created the service originally.
This commit runs another migration to wipe all the data, and replace it
using an operation that looks at the first version of the service in the
history table, which will reference the user who actually created the
service.
If a service has been created by someone on our team, it’s probably a
test service, which shouldn’t be included in the count of live services.
This commit adds a migration to do this for existing services.
Sometimes we have to make a few services for what really is one
service, for example GOV.UK Pay and GOV.UK Pay Direct Debit. We also
have our own test services which aren’t included in the count of live
services. We currently count these as one service by not including them
in the beta partners spreadsheet.
This adds a column to mark such services as ‘not counted’, which can
later be used to exclude them from reporting.
Now that notifications-admin is always sending through
folder_permissions, the folder_permissions column of the invited_user
table can be made non-nullable. The migration also backfills the column
(to []) to account for existing null values.
Added a new JSONB column, folder_permissions, to the invited_users table
to store a list of folders that an invited user can see. This is
nullable for now, but will be changed to be non-nullable and
back-populated later.
