c0ecf2fa3bebd46bdfd0169efd73b89653d1dfed
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 MattssonandClaude Fable 5
|
cd344b6dbb |
fix(db): enforce balance check on directly inserted posted journal entries (v2) (#1439)
* fix(db): enforce balance check on directly inserted posted journal entries check_balance_on_post only fires on the draft-to-posted UPDATE transition, so any code path that INSERTs a row with status 'posted' directly skipped balance validation entirely. The invariant sum(debit) = sum(credit) on every posted entry was DB-enforced only for the engine's commit lifecycle. Add check_balance_on_posted_insert, a deferred constraint trigger on AFTER INSERT WHEN (NEW.status = 'posted') reusing the existing check_journal_entry_balance() function, which already handles the journal_entries INSERT context via NEW.id/NEW.status. Deferred semantics let an atomic transaction insert header and lines together; zero-line and unbalanced posted inserts are rejected at constraint evaluation. All existing checks stay intact; this only adds coverage. The one first-party posted-INSERT path outside an RPC, the sandbox seed, now books through the bookkeeping engine (createJournalEntry) instead of raw inserts. SIE import already inserts header and lines in a single transaction via its structured RPC and passes unchanged. pg tests cover the new path (zero-line rejected, unbalanced rejected at SET CONSTRAINTS IMMEDIATE, balanced same-transaction insert accepted) and existing posted-entry fixtures move to a transactional insertPostedJournalEntry helper so they stay valid setup. Fixes #327 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(tests): insert list-filters pg fixtures in one transaction The list-filters suite (landed via a sibling merge) inserted posted headers with getPool().query, where each query autocommits: the deferred check_balance_on_posted_insert constraint fired at the header's own commit with zero lines and correctly rejected the fixture. Header and balanced lines now share one BEGIN/COMMIT so the constraint evaluates the complete entry, mirroring the insertPostedJournalEntry helper. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(seed): insert journal headers as drafts, post after lines land check_balance_on_posted_insert (renamed to apply-time version 20260806130000) rejects a posted header whose transaction has no lines. PostgREST autocommits each request, so every seed path that inserted posted headers first would die with "has zero total": the sandbox seed (ledger history, invoice vouchers, salary vouchers), seed-demo-account and seed-export-data. All now insert draft headers, insert lines, then flip to posted so check_balance_on_post validates the finished verifikat. The sandbox seed keeps its documented no-events design. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(db): preserve a preset committed_at on draft-to-posted transition set_committed_at() stamped now() unconditionally, so the seed flows that post backdated drafts lost their historical booking timestamps and every demo verifikat read as booked today (CodeRabbit finding on PR 1439). Stamp only when committed_at is NULL: the engine path (drafts carry no committed_at) behaves exactly as before and a posted entry still always has a committed_at; an explicitly supplied value now survives posting. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(db): preserve preset committed_at only for trusted roles The IS NULL guard alone (20260806150000, never shipped; replaced by 20260806160000) let any RLS-permitted member backdate committed_at through PostgREST by presetting it on a draft and posting, which the Swedish accounting review flagged: committed_at is what the BFL 5 kap timeliness checks and behandlingshistorik treat as the genuine transition time. Preset values now survive posting only for service_role/postgres/supabase_admin; authenticated and anon writers always get the now() stamp. Consequence: the sandbox seed (runs as the requesting user) gets committed_at = posting time, accepted and documented in the route; the demo scripts run as service_role and keep their backdated history. pg tests cover all four paths, with the upper timestamp bound CodeRabbit asked for. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(db): restore superseded migration so the preview tracker stays consistent The preview branch had already applied 20260806150000 when the previous commit deleted the file, orphaning the preview's migration tracker ("Remote migration versions not found in local migrations directory"). Restored with a header explaining it is superseded in the same deploy by 20260806160000, so the unguarded semantics are never live on their own. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(db): decide committed_at trust by JWT claims, not current_user The Swedish review found the current_user guard bypassable: commit_journal_entry is SECURITY DEFINER and granted to authenticated, so inside it current_user is the function owner and a member could preset a backdated committed_at on a direct-inserted draft and launder it through the RPC. The guard now reads the JWT claims role (same primitive as the RPC's own tenant guard): preset values survive only for service_role or claim-less backend connections; authenticated and anon callers are always stamped now(), on both the direct UPDATE and the RPC path (new pg test). Both migration files now carry the identical final body so no unguarded intermediate exists as a standalone applyable unit. Behandlingshistorik logging of trusted overrides is follow-up #1444. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Jakob WennbergandClaude Sonnet 5
|
ec27228a8e |
style: remove em/en dashes repo-wide, add CLAUDE.md rule against them (#890)
Em dashes (—) and en dashes (–) had spread across comments, docs, tests, and a few UI strings, reading as AI-generated boilerplate rather than house style. Replaced each with punctuation matching its context: colon for explanatory clauses, comma for asides, plain hyphen for numeric/legal ranges (e.g. "21-23§"), "to"/"till" for date ranges, parentheses for paired-dash asides. messages/en.json and messages/sv.json were fixed by hand together to keep sv/en in sync. Left untouched where the dash is the functional subject rather than decorative punctuation: date-range-parser.ts's separator regex, charset-repair.ts's CP1252 byte-mapping table (and its test), the SIE encoding mojibake docs, generic-csv.ts's minus-sign normalizer, the agent system-prompt files that already instruct against em dashes, and a golden iXBRL test fixture compared byte-for-byte. Also fixes two bugs surfaced along the way: an off-by-one in ApiKeysPanel's scope-label split (a leftover from an earlier partial pass), and a charset-repair test that had lost the literal en-dash it exists to verify. Regenerated the agent atom seed migration (skills:generate) since 27 SKILL.md files changed. Added a CLAUDE.md rule against em/en dashes, with an explicit carve-out for the functional-dash cases above. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Jakob WennbergandClaude Opus 4.8
|
358c25094d |
fix(security): tenant guard on the GL-line read RPCs (#625)
* fix(security): tenant guard on the GL-line read RPCs (PR #624 follow-up) get_unlinked_gl_lines and get_account_gl_lines_for_matching are SECURITY DEFINER and EXECUTE-able by anon/authenticated, so any authenticated (or anonymous) caller could invoke them directly over /rest/v1/rpc with another company's id and read its general-ledger lines — a cross-tenant read that bypasses the API routes' requireCompanyId() guard. Confirmed against the DB: anon and authenticated both hold EXECUTE, and SECURITY DEFINER sidesteps RLS. Add an in-function guard constraining anon/authenticated callers to their own companies (the same boundary user_company_ids()/RLS enforces). Trusted callers are untouched — service_role (the enable-banking reconciliation cron) and direct / superuser access (migrations, the pg-real harness) are not anon/authenticated, so the predicate is a no-op and behaviour is unchanged. A foreign company id now yields zero rows, not data. Scope: hardens the two READ RPCs that expose ledger data. The remaining company-scoped SECURITY DEFINER RPCs are writes / sequence generators with their own internal authorization; a broader audit of that set is tracked separately. pg-real coverage: a company-B member probing company A gets zero rows from both RPCs, while a company-A member and direct/superuser access still see the data. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(security): revoke EXECUTE from PUBLIC/anon on the GL-line read RPCs Defense-in-depth follow-up to the tenant guard. The guard already returns zero rows to an anon/authenticated caller probing another company; this additionally strips the EXECUTE privilege so an unauthenticated (anon) caller cannot invoke the financial-ledger RPCs at all. Supabase grants EXECUTE to PUBLIC as well as to anon, and anon is a member of PUBLIC — revoking only anon is insufficient, so revoke both, then keep the two legitimate callers: authenticated (the API routes call via the user's session; the in-function guard scopes them to their own companies) and service_role (the enable-banking reconciliation cron). Verified on the DB: anon EXECUTE = false, authenticated/service_role = true. Adds an anon-role pg test asserting the call is rejected at the privilege layer. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(security): read JWT role from claims object in the GL-line RPC guard The 20260611120000 guard used auth.role() to detect the caller's role, but auth.role() reads the individual request.jwt.claim.role GUC first and only some installs fall back to the claims object. PostgREST sets the claims OBJECT (the individual claim.* GUCs are deprecated), and the pg-real harness sets request.jwt.claims (+ claim.sub for auth.uid()) but NOT claim.role — so on an auth.role() without the object fallback it returns NULL and the guard's NOT IN ('anon','authenticated') branch was TRUE, skipping the membership check. A pg-real test caught it: an authenticated non-member could still read another company's GL lines (the guard failed open in that environment). Read the role straight from request.jwt.claims (exactly what auth.role() itself falls back to), so the guard enforces in every environment regardless of which JWT-claim GUCs are populated. Verified on the DB: an authenticated non-member evaluates both guard branches false → row excluded. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |