DataTalksClub / DataTalksClub/website
D3.1 phase 4: Remove the twelve moved fields from CustomUser (contract)
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
Part of the D3.1 umbrella (#334): phase 4 of 6. Contract step: removes the twelve moved fields and the moved unique constraint from CustomUser now that phases 2 and 3 have switched every reader.
Normative sources
| Source | What it governs |
|---|---|
community-base repo: docs/plan/phase-3.md D3.1 |
Contract step |
_docs/specs/09-migration-rollout-roadmap.md |
Expand-and-contract rollout policy: this is the "contract" half |
| Phases 2 (#391) and 3 (#392) | Reader migrations this issue assumes complete |
Goal
CustomUser no longer declares role, certificate_name, country, region, registration_role, github_url, linkedin_url, personal_website_url, about_me, dark_mode, normalized_email, identity_state, or the accounts_active_normalized_email_unique constraint. courses.LearnerProfile and accounts_ext.IdentityState are the sole source of truth. No behavior change to any reader — they were already reading the new models as of phase 2/3.
Scope
- Migration removing the twelve fields and the constraint from
CustomUser. - Full-repository grep confirming no remaining attribute access to the removed fields off
CustomUser/the auth model, outside migrations and theaccounts.services.cmp_learner_importsource-table string literals (accounts_customuser) andCmpLearnerImportProgress.tablevalues, which name the CMP export's source tables, not the live model, and are intentionally unaffected. - Re-run of the gallery-module regression test added in phase 2 to confirm it is still green after the fields are gone (it should never have depended on them).
Non-goals
- No rename (phase 5).
- No AISL field additions (phase 6).
- No change to
username,newsletter_subscribed,home_dismissals, ornewsletter_preference_changed_at(the last added toCustomUserafter #334's original grooming, alongsidenewsletter_subscribedin the BE-15 fix) — all four stay untouched; their eventual disposition isD3.2/C3.7adoption-time reconciliation, not this issue.
Dependencies
- Depends on: #391, #392 (both reader-migration phases must be merged and verified first).
- Blocks: #394 (rename cannot safely land while stale fields still exist to shadow the new profiles in a partial rebase).
Acceptance criteria
Django and integration
-
make django-check/make migrations-checkpass. -
make test(full suite) passes. -
CustomUserno longer declares the twelve fields oraccounts_active_normalized_email_unique; the constraint is enforced onaccounts_ext.IdentityStateonly. - A documented grep over tracked
.pyfiles (excluding migrations and the named CMP source-table literals) shows zero attribute access to the removed fields off the user model. -
manage.py migrateapplies cleanly end to end on a fresh database; the removal migration reverses, or its irreversibility is documented in the migration file.
Repository and operations
-
P14row-count rehearsal on a development database copy: counts before and after recorded, every difference explained by the phase 1 per-user profile tables plus this phase's column drop. If no development copy is reachable locally, recordNot run here, needs: P14 rehearsal on a development database copyand keep the issue open with thehumanlabel at acceptance. - Versioned verification plan per
_docs/ci/change-selective-ci.mdrecorded in the engineer handoff.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
First verify that phases 2 and 3 (#391 and #392) are merged, then read the CustomUser definition and the migration history alongside docs/plan/phase-3.md and _docs/specs/09-migration-rollout-roadmap.md. Run make django-check, make migrations-check, and the gallery regression test before making the removal migration; done means the full suite, fresh migrate, documented grep, reversal decision, and P14 handoff requirements are satisfied.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- django, python
- Domain
- backend, databases
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 45/100