c187fabf92
* feat(shopify): Shopify order/refund feed into the transactions inbox
New extensions/general/shopify feed extension, modeled on the WooCommerce
feed: connect a Shopify store with Dev Dashboard custom-app client
credentials (client credentials grant, ~24h tokens, never stored), then a
nightly cron + manual sync imports paid orders and refunds via the GraphQL
Admin API (pinned 2026-07) into the transactions inbox on clearing account
1584. Feed-only: nothing auto-books. Zero PII fields are queried, keeping
the app outside Shopify's protected customer data program.
- shopify_connections migration (RLS, revoke-never-delete, encrypted
client id/secret) + shopify_sync capability and bank_sync-mirrored
backfill
- frozen external_id scheme shopify_{shop_domain}_order|refund_{id},
scoped on the shop domain so reconnects never re-import
- cursor sync on updated_at windows with 24h overlap, lock-date drop at
map time, ingest-failure cursor floor, deadline stop-and-resume,
revoked-credential flip
- /import card + settings panel, sv/en i18n, cron 03:15 in vercel.json +
regenerated Docker crontabs, logo, events, panel registry
- 65 unit tests + pg-real RLS test; extensions.schema.json enum also
gains the missing stripe entry (pre-existing drift)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(shopify): review findings from PR 1474
- token exchange: a 429 that survives every retry is throttling, not a
credential failure; stop remapping retryable 4xx to 401 so sustained
throttling can no longer flip the connection to revoked and delete the
stored credentials (CodeRabbit critical)
- order sync: advance a scanned-through watermark (run start, capped by
the failure floor) after a fully-listed window, so empty first runs and
quiet stores rotate to the back of the cron's oldest-first selection
instead of permanently occupying the 50-connection batch (CodeRabbit
major, starvation)
- add handler-level tests for the orders cron route (auth 401, disabled
503, unconfigured no-op, query failure, capability skip, happy path,
per-connection failure isolation, revoked marking)
- add 401 tests for /sync, /transaction-sync and /disconnect; pin the
cursor floor rule with a two-order page; stub the encryption key via
vi.stubEnv
- note in the panel description (sv/en) that orders can mix VAT rates and
must be split at booking (Swedish review advisory)
- DECISIONS.md: wrap underscore identifiers in backticks (MD037)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
30 lines
1.2 KiB
SQL
30 lines
1.2 KiB
SQL
-- Backfill capability_grants for the new 'shopify_sync' capability.
|
|
--
|
|
-- shopify_sync joins PAID_CAPABILITIES, but existing companies' grants were
|
|
-- written by the billing webhook / trial seeding BEFORE this key existed, and
|
|
-- are only refreshed on the next subscription event. Without a backfill,
|
|
-- every current payer and trialer would see the Shopify integration as not
|
|
-- entitled until their next webhook. Mirror each existing bank_sync grant
|
|
-- (the same sibling used by the stripe_payments and woocommerce_sync
|
|
-- backfills, 20260712100100 / 20260806170100) with identical scope, source
|
|
-- and expiry, so entitlement state stays exactly aligned.
|
|
--
|
|
-- Idempotent: the (scope, key, source) unique index makes re-runs no-ops.
|
|
|
|
insert into public.capability_grants
|
|
(company_id, team_id, capability_key, source, granted_at, expires_at, metadata)
|
|
select
|
|
g.company_id,
|
|
g.team_id,
|
|
'shopify_sync',
|
|
g.source,
|
|
g.granted_at,
|
|
g.expires_at,
|
|
jsonb_build_object(
|
|
'backfilled_from', 'bank_sync',
|
|
'backfill_migration', '20260808150100'
|
|
)
|
|
from public.capability_grants g
|
|
where g.capability_key = 'bank_sync'
|
|
on conflict (company_id, team_id, capability_key, source) do nothing;
|