pf_app/routes
Paul Trowbridge 13e49c14b6 Offer negative clone offsets, and validate the interval before using it
Shifting backwards already worked -- the offset is added as a Postgres
interval, and '-90 days' is a perfectly good one -- but the suggestions only
listed forward shifts, so nothing said so. Pulling a plan back a quarter is
a normal thing to want.

A day-level shift is also the case that most needs the dim_period
derivation: 15 Mar 2027 less 90 days is 15 Dec 2026, which crosses from
2027/10 - Mar into 2027/07 - Dec. Copying the period columns across would
have labelled it March.

The offset is interpolated into the statement, so a typo surfaced as a
Postgres parse error from the middle of a CTE. It is parsed on its own
first, where the failure is cheap and can name the field.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-17 02:11:04 -04:00
..
auth.js Put the app behind a login 2026-09-14 22:20:25 -04:00
log.js Let a segment say what it counts toward, and pivot on it 2026-09-17 00:59:00 -04:00
operations.js Offer negative clone offsets, and validate the interval before using it 2026-09-17 02:11:04 -04:00
sources.js Keep master data for a dim_group instead of re-deriving it from the source 2026-09-17 00:19:39 -04:00
tables.js Expose pf_note/pf_op in forecast data; fix tables list duplicates 2026-04-28 19:51:45 -04:00
versions.js Complete recode values from the version, not the source view 2026-09-17 00:03:05 -04:00