pf_app/lib
Paul Trowbridge 5feb28eb76 Keep the pivot's pf_ columns in the slice, and log the panel's expected change
The ledger filtered on every column of the loaded table, while the request
kept only pf_segment and pf_bucket and stripped pf_iter, pf_note, pf_op,
pf_user and pf_logid. Under the default layout, grouped by pf_iter, a click
on a customer's `scale` row totalled the scale rows and wrote to every row
the customer has -- on GRIFFIN, $4.5M shown against $9.7M written. They now
travel: pf_iter / pf_user / pf_logid compared directly, pf_note / pf_op
resolved to log ids as pf_segment / pf_bucket are, a null note as IS NULL.
They narrow a slice but do not make one selective on their own.

Each scale also carries `expected`, the Result line as a change, and
`plug`, both kept in the log's params beside `resolved` so a panel/server
disagreement can be found by reading it. Nothing compares them yet.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 22:40:00 -04:00
..
auth.js Scope what an account can see and change to its territory 2026-09-18 11:14:03 -04:00
sql_generator.js Keep the pivot's pf_ columns in the slice, and log the panel's expected change 2026-09-28 22:40:00 -04:00
utils.js Read source columns from pg_catalog, not information_schema 2026-09-18 16:12:05 -04:00