One login integration migrations

[CatalinVoineag]

Context

We want to allow our candidates to login into apply with one login. We also want to allow them to recover their account if their one login email is different from the candidate's email.

These are all the migrations we need for our one login integration, to allow a candidate to login or recover their account.

This is based on the one login spike

Changes proposed in this pull request

We need to allow the user to reclaim their account with any code valid in the last 1 hour for example. That's why AccountRecoveryRequest has_many AccountRecoveryRequestCodes

erDiagram
    Candidate ||--o{ OmniAuthLogin : has_one
    Candidate ||--o{ AccountRecoveryRequest : has_one
    Candidate {
      string email_address
    }
    AccountRecoveryRequest ||--o{ AccountRecoveryRequestCode : has_many
    OmniAuthLogin {
      string token
      string email_address
      id candidate_id
    }
    AccountRecoveryRequest {
      string previous_account_email_address
      id candidate
    }
    AccountRecoveryRequestCode {
      string hashed_code
      id account_recovery_request_id
      datetime created_at
    }

Loading

Guidance to review

Does it make sense?

Things to check

• If the code removes any existing feature flags, a data migration has also been added to delete the entry from the database
• This code does not rely on migrations in the same Pull Request
• If this code includes a migration adding or changing columns, it also backfills existing records for consistency
• If this code adds a column to the DB, decide whether it needs to be in analytics yml file or analytics blocklist
• If this code adds a column that may include PII, the sanitise.sql script and 0025-protecting-personal-data-in-production-dump.md ADR have been updated.
• API release notes have been updated if necessary
• If it adds a significant user-facing change, is it documented in the CHANGELOG?
• Required environment variables have been updated added to the Azure KeyVault
• Inform data insights team due to database changes
• Make sure all information from the Trello card is in here
• Rebased main
• Cleaned commit history
• Tested by running locally
• Add PR link to Trello card

[CatalinVoineag]

Add one login migrations and feature flag

[dcyoung-dev]

We should split the migration, schema and analytics files into another PR which gets deployed first. Even though we're not using the code that relies on the migration in this instance, it's good practice.

[CatalinVoineag]

We should split the migration, schema and analytics files into another PR which gets deployed first. Even though we're not using the code that relies on the migration in this instance, it's good practice.

I don't think we can split models from migrations. DfE analytics will look for models that you created in migrations.

As long as the models being created are not called by views/controllers/apis/jobs we should be fine