6ea92f3152
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
89 lines
3.7 KiB
TypeScript
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,
|
|
}
|
|
}
|