Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

D3.1 phase 5: Rename CustomUser to User (RenameModel, AUTH_USER_MODEL)

Open
  • Is something wrong?
#394 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Refactor
Clarity
Clearly specified
Activity status
Active
Tech stack
django, python
Domain
authentication, backend, database, testing

Research direction

Confirm dependency #393, then read the current account model, migration history, settings, and accounts/identity_inventory.py, including the listed literal values. Run make django-check, make migrations-check, and the focused identity tests before the full suite and browser checks. Done means the rename preserves rows, resolves accounts.User with accounts_user, fixes import and literal fallout, and satisfies the stated grep and migration checks.

Written by the indexing model from the issue text.

Description

auth courses data-migration enhancement P1

Part of the D3.1 umbrella (#334): phase 5 of 6. P7 step 2's model rename, isolated as its own small, final-schema-shape step.

Normative sources

Source What it governs
community-base repo: docs/03-playbooks.md P7 DTC step 2 Rename procedure
#334, owner decision comment (2026-09-08) Confirms the AUTH_USER_MODEL setting-value change ships in the same deployable unit as the rename; only the rest of P7 step 5 (the get_user_model() idiom sweep, django_migrations cleanup) stays deferred
#334, grooming supplement comment (2026-09-08) The accounts/identity_inventory.py string-literal fallout this issue must fix

Goal

migrations.RenameModel("CustomUser", "User") and AlterModelTable to accounts_user, AUTH_USER_MODEL updated to "accounts.User" in the same change. End state: model accounts.User, table accounts_user, all rows preserved, zero behavior change.

Scope

  • The rename migration, using the operation sequence makemigrations generates.
  • AUTH_USER_MODEL = "accounts.User" in settings, landed atomically with the migration (Django cannot resolve the old model name after the rename — see the linked owner decision).
  • Fix every now-broken CustomUser import across the codebase.
  • accounts/identity_inventory.py literal fixes (do not skip — these live in string literals, so neither the import rewrite nor an attribute-access grep catches them):
    • ACCOUNT_MANY_TO_MANY_RELATIONS: "owner_model": "accounts.CustomUser", the "through_table" values accounts_customuser_groups/accounts_customuser_user_permissions (implicit m2m through tables rename with the model), "user_field": "customuser" (the reverse accessor becomes user).
    • ACCOUNT_RELATIONS's first entries: "accounts.CustomUser_groups"/"customuser".
    • By contrast, accounts_customuser literals in accounts/services/cmp_learner_import.py and CmpLearnerImportProgress.table values name the CMP export's source tables, not the live table, and must NOT be touched.
  • Verify current main for any further CustomUser-literal or accounts.CustomUser model-label string added since #334's original grooming (for example in accounts/tests/test_identity_quarantine_revocation.py, accounts/tests/test_username_allocation.py, and the management_auth/management_api modules touched by that same BE-08 fix) before finishing — this table is a floor, not the full inventory.

Non-goals

  • No get_user_model() idiom sweep beyond fixing imports the rename itself breaks.
  • No django_migrations cleanup, no squashed-migration --fake, no P5 relabel work.
  • No AISL field additions (phase 6).
  • No login-behavior, allauth-adapter, or permission-logic change beyond rename fallout.

Dependencies

  • Depends on: #393 (the contract phase must land first — renaming while stale duplicate fields still exist on CustomUser risks the rename migration and the field-removal migration racing on the same table during a rebase).
  • Blocks: D3.2 and C3.7 (per #334), and #395 (kept last to match the original plan's stated ordering; phase 6 is otherwise independent and could reorder if the owner prefers).

Acceptance criteria

Django and integration
  • make django-check / make migrations-check pass.
  • make test (full suite) passes.
  • get_user_model() resolves to accounts.User with db_table accounts_user.
  • Email login authenticates through the Django test client (login, session, member page 200); the dark-mode toggle endpoint still works end to end through learner_profile.
  • grep -rn "CustomUser\|accounts_customuser" --include=*.py . | grep -v migrations | grep -v .tmp shows only the CMP-import source-table literals and any deliberately preserved docstring/comment references; the PR body records this grep's output.
  • manage.py migrate applies cleanly end to end on a fresh database.
Browser
  • make test-playwright-core passes.
  • [HUMAN] After the development deploy: login with an existing development account works and the dark-mode toggle persists.
Repository and operations
  • Versioned verification plan per _docs/ci/change-selective-ci.md recorded in the engineer handoff.
Dominant language
Python
Stars
0
Forks
0
No merged PRs in 30d

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from DataTalksClub/website

All issues in DataTalksClub/website

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.