Steve Hanlon
631385721f
Lets a technician record when a site should next be looked at, and surfaces that in the dashboard so it can be used for planning. Server: - migration 0002 adds healthchecks.next_due, a VARCHAR(10) 'YYYY-MM-DD' calendar date rather than a timestamp — it's a diary date with no time-of-day, and a timestamp would render as the wrong day off-server. - Kept per-session rather than on a sites table, so the history of what was scheduled when is preserved. A site's current next-due is the value on its most recent session: if the latest visit scheduled nothing, the site reads as unscheduled rather than showing the just-completed visit as overdue. - Validate::optionalDate() round-trips through createFromFormat, which rejects both '2026-2-3' and '2026-02-30' (silently rolled to March 2nd). - next_due follows the same missing-vs-null PUT contract as finished_at, and lives in its own Store::setNextDue() so finishing or reopening a session never disturbs the date and vice versa. - Dashboard shows it on the site list, the per-site session table and the session detail, flagged overdue / today / soon (within a fortnight). Plugin: - Date control on both the active and finished panels — the moment you know when to return is often wrap-up, after the report is generated. - Write-through like every other mutation. Bad input is rejected with a notice rather than silently clearing an existing date. - Included in both the Markdown and HTML reports. Tests (new — tests/, export-ignored from the plugin zip): - Hand-rolled harness, no composer/PHPUnit, in keeping with the repo. - 42 tests: plugin-side date parsing units, plus server integration tests driven over real HTTP against a temp `php -S` instance with a throwaway SQLite DB, so a real server/config.php is never touched. - Mutation-checked: dropping the array_key_exists guard on PUT fails three tests, as intended.
19 lines
1004 B
SQL
19 lines
1004 B
SQL
-- Next healthcheck due date, recorded against the session that scheduled it.
|
|
--
|
|
-- Stored as a VARCHAR(10) 'YYYY-MM-DD' calendar date rather than a BIGINT unix
|
|
-- timestamp on purpose: this is a diary date a human picked ("look at this site
|
|
-- again in October"), not an instant. A timestamp would drag timezone handling
|
|
-- into something that has no time-of-day component, and would render as the
|
|
-- wrong day for anyone east or west of the server.
|
|
--
|
|
-- Kept per-session (not on a separate sites table) so the history of what was
|
|
-- scheduled when is preserved. A site's *current* next-due is the value on its
|
|
-- most recent session — see Store::allSitesSummary().
|
|
--
|
|
-- Portable: both MySQL 8 and SQLite accept ALTER TABLE ... ADD COLUMN with a
|
|
-- nullable typed column and no default. Neither supports ADD COLUMN IF NOT
|
|
-- EXISTS in a form the other understands, which is fine — Migrations.php only
|
|
-- ever applies each file once.
|
|
|
|
ALTER TABLE healthchecks ADD COLUMN next_due VARCHAR(10) NULL;
|