Removes the Ofsted Parent View feature ("What Parents Say" survey) across the whole stack, per request. The rest of the dbt layer — which builds every mart the backend reads — is left intact.
Frontend
Drop the OfstedParentView type and the parent_view field from the school-details response type.
Remove the "What Parents Say" section, the "X% of parents would recommend" callouts, and the Parents nav item from both SchoolDetailView and SecondarySchoolDetailView, plus the now-dead parent-view CSS in both modules.
Remove the parentView prop plumbing in app/school/[slug]/page.tsx.
Backend
Remove the FactParentView model, its loading in data_loader.py, and parent_view from the /api/schools/{urn} response.
Bump SCHEMA_VERSION 5 → 6 with a changelog entry, and add an idempotent drop step (DROP TABLE IF EXISTS marts.fact_parent_view CASCADE) to the CLI migration.
Add scripts/sql/drop_fact_parent_view.sql — the marts schema is dbt-owned, so this is the reliable path to drop the table directly on the staging and production marts databases.
Pipeline
Delete the stg_parent_view and fact_parent_view dbt models and their source/schema entries.
Delete the tap-uk-parent-view Meltano extractor and remove it from meltano.yml and the pipeline Dockerfile.
Remove the monthly school_data_monthly_parent_view Airflow DAG and its mention in the staging bootstrap steps in docs/DEPLOY.md.
Verification
Frontend typecheck + 33 unit tests pass; backend and DAG py_compile clean; all three edited YAML configs parse. Full-repo grep confirms no remaining Parent View references outside the intended migration/changelog entries.
Post-merge: apply scripts/sql/drop_fact_parent_view.sql (or let the CLI migration's drop step run) against the staging and prod marts DBs to physically drop the retired table. The school-detail e2e journey covers that the page still renders without the section.
Removes the Ofsted **Parent View** feature ("What Parents Say" survey) across the whole stack, per request. The rest of the dbt layer — which builds every mart the backend reads — is left intact.
## Frontend
- Drop the `OfstedParentView` type and the `parent_view` field from the school-details response type.
- Remove the "What Parents Say" section, the "X% of parents would recommend" callouts, and the **Parents** nav item from both `SchoolDetailView` and `SecondarySchoolDetailView`, plus the now-dead parent-view CSS in both modules.
- Remove the `parentView` prop plumbing in `app/school/[slug]/page.tsx`.
## Backend
- Remove the `FactParentView` model, its loading in `data_loader.py`, and `parent_view` from the `/api/schools/{urn}` response.
- Bump `SCHEMA_VERSION` 5 → 6 with a changelog entry, and add an idempotent drop step (`DROP TABLE IF EXISTS marts.fact_parent_view CASCADE`) to the CLI migration.
- Add `scripts/sql/drop_fact_parent_view.sql` — the marts schema is dbt-owned, so this is the reliable path to drop the table directly on the staging and production marts databases.
## Pipeline
- Delete the `stg_parent_view` and `fact_parent_view` dbt models and their source/schema entries.
- Delete the `tap-uk-parent-view` Meltano extractor and remove it from `meltano.yml` and the pipeline `Dockerfile`.
- Remove the monthly `school_data_monthly_parent_view` Airflow DAG and its mention in the staging bootstrap steps in `docs/DEPLOY.md`.
## Verification
Frontend typecheck + 33 unit tests pass; backend and DAG `py_compile` clean; all three edited YAML configs parse. Full-repo grep confirms no remaining Parent View references outside the intended migration/changelog entries.
**Post-merge**: apply `scripts/sql/drop_fact_parent_view.sql` (or let the CLI migration's drop step run) against the staging and prod marts DBs to physically drop the retired table. The school-detail e2e journey covers that the page still renders without the section.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Removes the 'What Parents Say' section and all supporting elements:
Frontend:
- Drop the OfstedParentView type, the parent_view field, the survey
section and the 'X% would recommend' callouts in the primary and
secondary detail views, the Parents nav item, and the parent-view CSS.
Backend:
- Remove the FactParentView model, its loading in data_loader, and
parent_view from the school-details API response.
- Bump SCHEMA_VERSION to 6 and add an idempotent drop step
(DROP TABLE IF EXISTS marts.fact_parent_view) to the CLI migration;
add scripts/sql/drop_fact_parent_view.sql to apply directly to the
dbt-owned marts DBs on staging and prod.
Pipeline:
- Delete the stg_parent_view + fact_parent_view dbt models and their
source/schema entries, the tap-uk-parent-view Meltano extractor, and
the monthly Parent View DAG; drop it from the Dockerfile and the
staging bootstrap docs.
The rest of dbt (which builds every mart the app reads) is untouched.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This PR cleanly removes the Ofsted Parent View feature end-to-end: the FastAPI response field and DB model/query, the Next.js UI sections/types/CSS, the Airflow monthly DAG, the meltano tap plugin and its dbt staging/mart models, plus a schema-version bump with an idempotent DROP TABLE migration and a standalone SQL script for manually retiring the mart table in staging/production. I verified there are no dangling references to parent_view/OfstedParentView/tap-uk-parent-view anywhere in the backend, frontend, pipeline, or CI configuration.
✅ No issues found.
## 🤖 AI Code Review (Claude Code)
This PR cleanly removes the Ofsted Parent View feature end-to-end: the FastAPI response field and DB model/query, the Next.js UI sections/types/CSS, the Airflow monthly DAG, the meltano tap plugin and its dbt staging/mart models, plus a schema-version bump with an idempotent DROP TABLE migration and a standalone SQL script for manually retiring the mart table in staging/production. I verified there are no dangling references to parent_view/OfstedParentView/tap-uk-parent-view anywhere in the backend, frontend, pipeline, or CI configuration.
✅ No issues found.
tudor
merged commit 5c39131b50 into main2026-07-06 08:31:00 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Removes the Ofsted Parent View feature ("What Parents Say" survey) across the whole stack, per request. The rest of the dbt layer — which builds every mart the backend reads — is left intact.
Frontend
OfstedParentViewtype and theparent_viewfield from the school-details response type.SchoolDetailViewandSecondarySchoolDetailView, plus the now-dead parent-view CSS in both modules.parentViewprop plumbing inapp/school/[slug]/page.tsx.Backend
FactParentViewmodel, its loading indata_loader.py, andparent_viewfrom the/api/schools/{urn}response.SCHEMA_VERSION5 → 6 with a changelog entry, and add an idempotent drop step (DROP TABLE IF EXISTS marts.fact_parent_view CASCADE) to the CLI migration.scripts/sql/drop_fact_parent_view.sql— the marts schema is dbt-owned, so this is the reliable path to drop the table directly on the staging and production marts databases.Pipeline
stg_parent_viewandfact_parent_viewdbt models and their source/schema entries.tap-uk-parent-viewMeltano extractor and remove it frommeltano.ymland the pipelineDockerfile.school_data_monthly_parent_viewAirflow DAG and its mention in the staging bootstrap steps indocs/DEPLOY.md.Verification
Frontend typecheck + 33 unit tests pass; backend and DAG
py_compileclean; all three edited YAML configs parse. Full-repo grep confirms no remaining Parent View references outside the intended migration/changelog entries.Post-merge: apply
scripts/sql/drop_fact_parent_view.sql(or let the CLI migration's drop step run) against the staging and prod marts DBs to physically drop the retired table. The school-detail e2e journey covers that the page still renders without the section.🤖 Generated with Claude Code
🤖 AI Code Review (Claude Code)
This PR cleanly removes the Ofsted Parent View feature end-to-end: the FastAPI response field and DB model/query, the Next.js UI sections/types/CSS, the Airflow monthly DAG, the meltano tap plugin and its dbt staging/mart models, plus a schema-version bump with an idempotent DROP TABLE migration and a standalone SQL script for manually retiring the mart table in staging/production. I verified there are no dangling references to parent_view/OfstedParentView/tap-uk-parent-view anywhere in the backend, frontend, pipeline, or CI configuration.
✅ No issues found.