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

D3.1 phase 2: Switch course-platform readers to courses.LearnerProfile

Open
  • Is something wrong?
#391 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

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

Research direction

Start with the D3.1 sources, phase 1 issue #390, and a grep-backed inventory across the listed views, forms, services, API files, and gallery modules. Run the Django checks and relevant test suites, including the gallery regression and Playwright core tests. Done means all ten fields read and write through user.learner_profile, gallery access remains pinned, and the acceptance checks pass.

Written by the indexing model from the issue text.

Description

auth courses data-migration enhancement P1

Part of the D3.1 umbrella (#334): phase 2 of 6. Switches the course-platform reader surface for the ten courses.LearnerProfile fields, refreshed against current main.

Normative sources

Source What it governs
community-base repo: docs/plan/phase-3.md D3.1; docs/03-playbooks.md P7 DTC step 3 (reader rewrite) Reader-migration expectation
Phase 1 issue (#390) courses.LearnerProfile model this phase reads/writes

Goal

Every read and write of role, certificate_name, country, region, registration_role, github_url, linkedin_url, personal_website_url, about_me, dark_mode goes through user.learner_profile instead of the CustomUser field. CustomUser's own fields are not removed yet (phase 4) — both are kept in sync so this can land, be verified, and merge on its own before the next reader batch is ready, without blocking on it.

Scope: reader surface (verify each by reading current main, this table is a starting point not exhaustive — grep before finishing)

Area Files
Dark mode course_management/context_processors.py, accounts/views/account_toggles.py
Registration and profile forms courses/views/registration_form.py, courses/views/registration_profile.py, courses/views/forms.py, accounts/forms.py, accounts/views/welcome.py
Projects and API courses/views/project_page_context.py, courses/views/project_submission_edit.py, api/views/enrollment_graduates.py
Member home courses/services/member_home.py
Cross-cohort/site project galleries (new since #334's original grooming, merged to main this cycle) courses/views/project_gallery_groups.py, courses/views/family_project_gallery.py, courses/views/site_project_gallery.py and their templates courses/templates/projects/family_gallery.html, courses/templates/projects/site_gallery.html

Verified read of the gallery module for this issue: as of current main, none of project_gallery_groups.py/family_project_gallery.py/site_project_gallery.py or their templates dereference any CustomUser/LearnerProfile field today — they only group Project/ProjectSubmission by cohort/family and render counts (project.submissions_count, group.projects|length). ProjectSubmission.student is a live FK to the user model (courses/models/project.py, via get_user_model(), not a hardcoded CustomUser import) that this module does not currently dereference. Action for this issue: add a regression test pinning that these three view modules and their templates still resolve zero LearnerProfile/moved-field attribute accesses, so a future change to the gallery that starts rendering submitter role/certificate/links is forced to go through learner_profile from day one instead of reintroducing a CustomUser field read.

Non-goals

  • No change to identity_state/normalized_email readers (phase 3).
  • No removal of the fields from CustomUser (phase 4).
  • No rename (phase 5), no AISL field additions (phase 6).
  • No community_base imports.

Dependencies

  • Depends on: #390 (courses.LearnerProfile must exist and be backfilled).
  • Blocks: #393 (contract removal needs every reader confirmed migrated first).

Acceptance criteria

Django and integration
  • make django-check / make migrations-check pass (no model change expected in this phase; flag if one becomes necessary).
  • make test passes.
  • A grep-backed inventory in the PR body lists every file that read/wrote the ten fields before this change and confirms each now goes through learner_profile.
  • The new gallery-module regression test (above) exists and passes.
  • Writes to dark_mode, certificate_name, profile URLs, about_me, role, registration_role, country/region via the account-settings and registration forms still round-trip through the Django test client.
Browser
  • make test-playwright-core passes: a signed-in member toggles dark mode and the preference survives reload; the registration form still remembers the last-used role.
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.