Follow-up to the previous commit — page.tsx now passes
default_qr_logo of type "wownero" | "monero" | "none" | "custom" to
this component, but the prop was still typed as the narrower
"monero" | "none" | "custom" set. Next build failed with TS2322.
Widened initialLogo prop + the internal useState + buildInitialState
helper to match.
ProfileResponse schema's default_qr_logo literal was inherited from
xmrcheckout: Literal["monero", "none", "custom"]. The DB column
(models.py) defaults to "wownero" and main.py's migration backfills
NULL → ... but the backfill also wrote "monero", contradicting the
column default.
End result: new users got default_qr_logo="wownero" (from the
column default), but GET /api/core/profile blew up with a Pydantic
ResponseValidationError on serialization because "wownero" isn't in
the literal. UI showed "Unavailable" for both Store ID and Primary
Address because the entire profile response 500'd, leaving
profileData null on the dashboard. API key + webhook secret rendered
fine because those come from cookies, not profileData.
Fix:
- schemas.py: QrLogoMode now Literal["wownero", "monero", "none",
"custom"] (keep "monero" for backward compat with any rows from
before the migration ran)
- schemas.py: ProfileResponse.default_qr_logo default → "wownero"
- main.py: backfill UPDATE → 'wownero' (was 'monero'); migration
column DEFAULT already correct as 'wownero'
- ui/dashboard/page.tsx: TS type for default_qr_logo widened to
include "wownero"; fallback default → "wownero"
- ui/dashboard/actions.ts: DefaultQrLogoState.logo type widened;
validation in updateDefaultQrLogo + initialMetadataPayload now
accepts "wownero"
Suchshop didn't hit this because their wowcheckout user row was
created back when this UI path wasn't being used (they were
provisioned via direct SQL/API). The new shop.wowne.ro merchant
created via the UI today triggered the column default → exposed
the schema mismatch.
isLikelyPrimaryAddress() required exactly 95 chars starting with "4"
— that's the Monero primary-address shape. Wownero primaries are 97
chars starting with "Wo". This was inherited from the xmrcheckout
fork and never updated.
Effect: pasting a valid Wownero address into the login form silently
failed isLikelyPrimaryAddress(), the validate API was never called,
no green VALID indicator rendered, canSubmit stayed false, the Sign
in button stayed greyed out. Suchshop sidestepped this because that
tenant was provisioned via direct SQL/API, not through this form.
Fix: 95 → 97, "4" → "Wo". One file, two lines.
The backend cryptographic validation in routes.py:
_validate_payment_address_and_view_key() was correct all along — it
checks the 2-byte Wownero varint prefix (byte 0 == 178). The UI just
wasn't asking it.
The checkout UI only redirected when status was 'confirmed' (after all
N confirmations). Now also redirects on 'payment_detected' (0-conf in
mempool). This matches BTCPay's behavior for BTC/LTC where the customer
is redirected to the store immediately on detection.
- POST/GET/DELETE /api/admin/users endpoints
- Admin UI at /admin with login, user list, create/delete
- Auth via ADMIN_API_KEY env var (separate from tenant auth)
- Tenants remain scoped to their own store only
jwinterm