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.
Currently we have
- a thing in the database called an ‘organisation’ which we don’t use
- the idea of an organisation which we derive from the user’s email
address and is used to set the default branding for their service and
determine whether they’ve signed the MOU
We should make these two things into one thing, by storing everything
we know about an organisation against that organisation in the database.
This will be much less laborious than storing it in a YAML file that
needs a deploy every time it’s updated.
An organisation can now have:
- domains which we can use to automatically associate services with it
(eg anyone whose email address ends in `dwp.gsi.gov.uk` gets services
they create associated to the DWP organisation)
- default letter branding for any new services
- default email branding for any new services
It should be nullable so we can tell whether someone has answered the
question already or not.
No real users have entered data into this column yet, so it’s fine to
wipe it.
Changed the user_to_service mapping table into a model called
ServiceUser. When looking at users who have permission for a folder
we are only interested in users for a particular service, not all users,
so we can use the ServiceUser model to access folder permissions.
Added a user_folder_permissions table which contains the service_id,
user_id and template_folder_id. There are links between
user_folder_permissions and TemplateFolder, and between
user_folder_permissions and ServiceUser.
It makes most sense to collect this at the same time as the estimated
volumes. Which means we need to store it somewhere; we can’t put it
straight into the ticket.
This will make it easier to do analysis on the data. Almost all users
are submitting data in a numerical format now anyway, because we ask the
question in a sensible way.
When a service go live we ask people for their estimated sending
volumes. At the moment we only put this in the ticket, and store it in
a spreadsheet.
This means that a service can
- say they want to go live
- say they are sending 100,000 emails per year
- not have created any email templates
- still see ‘create templates’ as ‘completed’ in the go live checklist
If we store this data against the service we can collect it earlier, and
then use it to determine automatically what kind of templates the user
needs to create before their go live checklist can be considered
complete.
Also change constraint on template postage so it cannot be null for
letters
Also add postage to all letters in template_history to respect new constraint
However, until we can create a letter without a logo, we will still default to hm-government, because the dvla_organisation is set on the service.
This does simplify the code.
Also removed the inserts to letter_branding in the data migration file, because we can deploy this before the rest of the work is finished. But we will need to do it later.
