777c7c6dcc
Konrad-approved design to fully remove the SiteReport / "Log Today's Work" feature (drop core_sitereport, no backup, revert post-attendance to redirect-home). Capture doc preserves the schema-as-Python pattern, the flow, recovery pointers, and rebuild guidance. Local-only; the removal itself is HARD-STOPPED before push. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
113 lines
5.4 KiB
Markdown
113 lines
5.4 KiB
Markdown
# SiteReport / "Log Today's Work" — Removed; Future-Rebuild Capture
|
|
|
|
**Date removed:** 17 May 2026
|
|
**Why this doc exists:** Konrad removed the SiteReport feature to
|
|
rethink site-progress logging **from scratch, separately**. This file
|
|
preserves everything worth knowing so a future session can rebuild it
|
|
without re-deriving the design — and without resurrecting code that no
|
|
longer fits.
|
|
|
|
> **Status: NOT a plan. Do NOT implement from this file.** It is a
|
|
> knowledge capsule. A future rebuild starts with a fresh
|
|
> brainstorming pass (see "When you rebuild" at the bottom).
|
|
|
|
## Why it was removed (the important part)
|
|
|
|
The on-site work mix is changing. The original feature was modelled
|
|
around a solar-farm foundation workflow (plinths cast, plinth holes
|
|
dug, boxes placed, steel placed, …). Konrad's words: *"we might start
|
|
piling and not cast so many plinths anymore so the scope might get
|
|
bigger or smaller."* The metric set — and whether a fixed metric set is
|
|
even the right model — is genuinely unknown. Half-fitting code on a
|
|
daily-use path is worse than a clean slate. So: full removal now,
|
|
deliberate redesign later when the new workflow is clearer.
|
|
|
|
Konrad explicitly accepted **irreversible loss of existing SiteReport
|
|
rows** (no backup taken) — the data was lightly used and not worth
|
|
carrying into a redesign.
|
|
|
|
## What it did (so you don't have to reverse-engineer it)
|
|
|
|
A `SiteReport` model, **optional 1:1 with `WorkLog`** (a WorkLog with
|
|
no report was a normal historical row). Fields:
|
|
|
|
- `weather` (choices: sunny/cloudy/rain/storm/hot/cold/windy),
|
|
`temperature_min` / `temperature_max` (°C, IntegerField),
|
|
free-form `notes`, `created_by`, `created_at`, `updated_at`.
|
|
- `metrics` — a `JSONField` of shape
|
|
`{'counts': {key: int}, 'checks': {key: bool}}`.
|
|
|
|
### The one genuinely good idea worth keeping: schema-as-Python, no migration
|
|
|
|
The metric **keys were NOT model columns**. They lived in a single
|
|
Python file `core/site_report_schema.py` (`COUNT_METRICS`,
|
|
`CHECK_METRICS`, `label_for()`). Adding/removing/renaming a metric was a
|
|
one-line edit + redeploy — **no DB migration**, old rows degrade
|
|
gracefully (missing key → 0/unchecked; retired key still shows via
|
|
`label_for` fallback). `SiteReportForm` iterated the schema at
|
|
`__init__` to build dynamic `IntegerField`/`BooleanField`s and
|
|
serialised back into the JSON blob on `save()`.
|
|
|
|
**This pattern is the single most reusable lesson.** Given Konrad's
|
|
"scope may get bigger or smaller" concern, a flexible-by-default schema
|
|
(JSON blob + a Python/DB-driven field list) is almost certainly the
|
|
right foundation again — possibly upgraded to an admin-managed
|
|
`MetricTemplate` model if per-project metric sets diverge.
|
|
|
|
### The flow it was wired into
|
|
|
|
Two-step: `attendance_log` POST (success) → redirect to
|
|
`/site-report/<work_log_id>/edit/` (mobile-first form, "Skip" link to
|
|
home). Read-only view at `/site-report/<work_log_id>/`. Permission:
|
|
admin, or supervisor of the WorkLog's team/project. On removal the flow
|
|
reverted to the original **redirect → home + success toast**.
|
|
|
|
## Prior thinking already on disk (mine these, then move past them)
|
|
|
|
- `docs/plans/2026-05-15-post-attendance-flow-v2-design.md` +
|
|
`-plan.md` — a *fully designed, Konrad-approved-but-never-built*
|
|
rework of this flow: replace the forced redirect with 3 explicit
|
|
buttons (Log Work → dashboard / + Site Journal / + Absences), plus a
|
|
"Save + Add Absences" button; and a Path-A display-only rename
|
|
"Site Report" → **"Site Journal"** (to free the word "Journal" for
|
|
the parked voice-notes feature). **Superseded by the removal** — the
|
|
flow it modified no longer exists. Kept on disk because the
|
|
button-hierarchy and naming-collision analysis are good raw material.
|
|
- `docs/plans/2026-05-17-site-report-removal-design.md` — the removal
|
|
design that this capture accompanies.
|
|
|
|
## How to recover the deleted implementation if you want a reference
|
|
|
|
The full original implementation is in git history. The recovery point
|
|
is **the commit immediately before `0018_delete_sitereport` landed** on
|
|
`ai-dev`. To find and read any deleted file:
|
|
|
|
```
|
|
git log --oneline -- core/site_report_schema.py # last commit is the recovery point
|
|
git show <that_sha>:core/site_report_schema.py
|
|
git show <that_sha>:core/models.py # SiteReport class
|
|
git show <that_sha>:core/forms.py # SiteReportForm
|
|
git show <that_sha>:core/views.py # site_report_edit / _detail / _can_access_site_report
|
|
git show <that_sha>:core/templates/core/site_report_edit.html
|
|
```
|
|
|
|
Nothing is lost from *code* history — only the production *table* and
|
|
its rows were dropped.
|
|
|
|
## When you rebuild (guidance, not a plan)
|
|
|
|
1. **Brainstorm first** — the new workflow (piling vs casting, etc.)
|
|
must drive the metric model. Do not start from the old metric list.
|
|
2. **Keep the JSON-blob + Python/admin-driven schema** idea — it is the
|
|
right answer to "scope may change." Decide early: fixed global
|
|
schema vs per-project `MetricTemplate`.
|
|
3. **Decide the flow deliberately** — the v2 design's "3 explicit
|
|
buttons, no forced redirect" instinct was sound; revisit it with
|
|
fresh eyes against the new workflow.
|
|
4. **Re-evaluate the model name** — "SiteReport" / "Site Journal" /
|
|
something else; mind the parked voice-notes "Journal" collision
|
|
noted in the Backburner section of `parked-work.md`.
|
|
5. New design doc + plan under `docs/plans/`, normal
|
|
brainstorm → writing-plans → subagent execution, HARD STOP before
|
|
push (it touches the daily attendance path).
|