Files
accounted/lib/dashboard/nav-flags.ts
T
Mattsson 6ea92f3152 feat(zettle): sync paid purchases into webshop_orders (#2445)
Community PR #2416 by @olofpinzke, adopted and finished by maintainers (rebased so every commit is signed).

Why the problem occurred: no Zettle integration; POS sales only reached the books as bank descriptors while Woo/Shopify already had order underlag via webshop_orders. The contributor's version also failed at the database (platform CHECKs listed only woocommerce/shopify), which the mocked unit tests never saw.
What was simplified: reused the Orders/book/invoice path instead of a new inbox; Finance API payouts/fees deferred. Sales the one-account, revenue-per-rate model cannot book (split tender, gift cards, tips) import unbookable with a "bokför manuellt" title instead of guessing accounts. Reset parity uses the rename-and-wrap pattern instead of re-issuing the reset body.
Why this solution: per-purchase rows give the radunderlag BFL verifikat need and the bulk-book path exists; daily kassarapport aggregation and Finance API fees/payouts are the follow-up (DECISIONS.md). Skeptic-refuted paths fixed before merge: concurrent refresh-token rotation (sync claim), cron offset paging (candidate snapshot), platform CHECKs, writer-role gate, migration-reset parity, white-label return origin re-validated at callback, VAT net from product rows.

Not live until ZETTLE_CLIENT_ID / ZETTLE_CLIENT_SECRET / ZETTLE_CREDENTIALS_ENCRYPTION_KEY are set on Vercel and a Zettle developer app is registered with the callback redirect URI.

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WtYqzKPoTSRHskYYdf7MwB
2026-09-09 11:19:39 +02:00

89 lines
3.7 KiB
TypeScript

import type { SupabaseClient } from '@supabase/supabase-js'
export interface DashboardNavFlags {
/** An active WooCommerce/Shopify connection or already-imported webshop orders. */
hasWebshop: boolean
/** Existing mileage trips (created via UI, API or MCP). */
hasMileageTrips: boolean
/**
* Existing expense claims (utlägg). Gates the Utlägg nav row the same way
* trips gate Körjournal: the entry point for a new utlägg is the Underlag
* pane ("Vem betalade?"), so the page only earns a rail row once there is
* something on it (a person to pay out).
*/
hasExpenseClaims: boolean
}
const FALLBACK_CODES = new Set(['PGRST202', '42883', '42501'])
/**
* The two booleans that gate the Webshop and Körjournal nav rows, in one
* round trip via get_dashboard_nav_flags() (migration 20260826120000).
*
* Fallback to the four limit-1 probes the layout ran before the RPC when
* the function is not deployed yet (self-hosted instance not migrated, or
* the deploy-ordering window before the branching merge applies the
* migration) or EXECUTE is not granted: mirrors the load-bearing fallback
* in lib/company/context.ts. Any other error degrades to (false, false):
* these flags only hide nav rows, they are never load-bearing.
*/
export async function getDashboardNavFlags(
supabase: SupabaseClient,
companyId: string,
): Promise<DashboardNavFlags> {
// The expense probe runs beside the RPC rather than inside it: extending
// get_dashboard_nav_flags would need a migration for one limit-1 read, and
// the two waves overlap so the layout pays no extra round trip.
const [rpc, expenseClaims] = await Promise.all([
supabase.rpc('get_dashboard_nav_flags', { p_company_id: companyId }),
probeExpenseClaims(supabase, companyId),
])
if (!rpc.error) {
const row = (Array.isArray(rpc.data) ? rpc.data[0] : rpc.data) as
| { has_webshop?: boolean | null; has_mileage_trips?: boolean | null }
| null
| undefined
return {
hasWebshop: row?.has_webshop === true,
hasMileageTrips: row?.has_mileage_trips === true,
hasExpenseClaims: expenseClaims,
}
}
if (!FALLBACK_CODES.has(rpc.error.code ?? '')) {
return { hasWebshop: false, hasMileageTrips: false, hasExpenseClaims: expenseClaims }
}
return { ...(await getDashboardNavFlagsViaProbes(supabase, companyId)), hasExpenseClaims: expenseClaims }
}
async function probeExpenseClaims(supabase: SupabaseClient, companyId: string): Promise<boolean> {
const { data, error } = await supabase
.from('expense_claims')
.select('id')
.eq('company_id', companyId)
.limit(1)
// A failed probe hides the row; the page and API work regardless.
return !error && (data?.length ?? 0) > 0
}
/** The pre-RPC implementation, kept verbatim as the fallback. */
export async function getDashboardNavFlagsViaProbes(
supabase: SupabaseClient,
companyId: string,
): Promise<Omit<DashboardNavFlags, 'hasExpenseClaims'>> {
const [woo, shopify, zettle, orders, trips] = await Promise.all([
supabase.from('woocommerce_connections').select('id').eq('company_id', companyId).eq('status', 'active').limit(1),
supabase.from('shopify_connections').select('id').eq('company_id', companyId).eq('status', 'active').limit(1),
supabase.from('zettle_connections').select('id').eq('company_id', companyId).eq('status', 'active').limit(1),
supabase.from('webshop_orders').select('id').eq('company_id', companyId).limit(1),
supabase.from('mileage_trips').select('id').eq('company_id', companyId).limit(1),
])
return {
hasWebshop:
(woo.data?.length ?? 0) > 0 ||
(shopify.data?.length ?? 0) > 0 ||
(zettle.data?.length ?? 0) > 0 ||
(orders.data?.length ?? 0) > 0,
hasMileageTrips: (trips.data?.length ?? 0) > 0,
}
}