pf_app/setup_sql
Paul Trowbridge 91c53ac6d8 Land on the forecast somebody chose, not the newest one
App.jsx fell back to versions[0] when localStorage held no selection, and
the version list is ordered created_at DESC -- so a fresh browser landed on
whatever version was created last. That is a scratch scenario as readily as
the plan, and sales accounts, which never pick a version themselves, had no
way back to the one they were meant to read.

pf.version.is_default names the landing version, at most one per source by
partial unique index, the way pf.layout.is_default already works. Setting it
is admin-only and enforced in the route: it decides where everyone else
lands, so it follows the pf.log rule rather than being the version's own
setting like its name.

A stored selection still wins -- the default is the fallback, not an
override, so nobody building scenarios is thrown back to the plan on every
load.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-22 08:34:46 -04:00
..
01_schema.sql Land on the forecast somebody chose, not the newest one 2026-09-22 08:34:46 -04:00
02_auth.sql Scope what an account can see and change to its territory 2026-09-18 11:14:03 -04:00
gen_dim_period.sql Add dim_group to col_meta and pf.dim_period calendar table 2026-05-23 01:46:16 -04:00