Upvendo Knowledge Base

Appearance

Demo Standard (QA Onboarding Bypass) ​

Overview ​

demo-standard is not a real POS provider. It is one of three QA-only "demo POS channel" keys (demo-minimal, demo-standard, demo-full) used to bypass onboarding so QA / Playwright tests can reach post-POS features (Online Ordering, menus, devices) without connecting and testing a real POS integration.

It exists only in the back-office frontend. There is no demo-standard provider, route, or record in the backend, and it is not offered in the Guided Setup POS selection grid (POS_PROVIDERS only ever contains real providers — Upvendo POS, Hendrickx and Vanhoutte in production, plus Square/Shopcaisse/MplusKassa/Lightspeed in dev/test).

Important: The bypass is gated by isTestEnv (the build environment is not production or staging). It can never activate in production.

Note: All three demo channels (demo-minimal, demo-standard, demo-full) are treated identically in the code. There is no behavioral difference between them — demo-standard does not enable "more features than minimal." The three keys exist as distinct values, but the bypass logic does the same thing for any of them.

How It Works ​

The bypass is implemented in the app store module (src/store/modules/app.ts):

  • The demo channel keys are defined as DEMO_POS_CHANNELS = ['demo-minimal', 'demo-standard', 'demo-full'].
  • When isTestEnv is true and localStorage key qa_demo_provider holds one of those keys:
    • fetchOnboardingState short-circuits and commits a simulated completed onboarding state: { pos_provider: <demo key>, phase: 'completed', setup_steps: [], completed_steps: [], answers: {} }. It logs [QA Mode] Demo provider active: … - POS connected simulated.
    • getAvailableInHouseChannelKeys injects the demo key into the available in-house channel list so "requires a POS" gates (e.g. the Kiosk option on device management) pass.
    • POS_CHANNELS includes the demo keys in test env, so hasPOSConnected checks succeed.
    • EmilyWidget.vue's isQADemoMode returns true, and the widget lets the store state drive the onboarding phase instead of forcing it.

Net effect: onboarding appears already complete with no setup steps — the opposite of a step-by-step setup flow.

Integration Type ​

  • Scope: Frontend QA bypass only (no real integration; nothing is created in the backend)
  • Real POS provider?: No
  • Payment processing: None (no real or simulated payments are created by the bypass)
  • Setup steps: None — onboarding is forced to phase: 'completed' with empty setup_steps
  • Branding / payment / billing prerequisite: None enforced by the bypass
  • Location / menu auto-creation: None — the bypass does not create any location, menu, or payment configuration

Activation ​

The bypass is driven entirely by a localStorage flag; there is no URL parameter for it.

typescript
// Activate the QA demo bypass (test environments only)
await page.evaluate(() =>
  localStorage.setItem('qa_demo_provider', 'demo-standard')
)
// Reload so the store picks up the injected channel on next state read
await page.reload()

This is the exact pattern used by the e2e device-management page object (e2e/pages/devices.page.ts), which sets qa_demo_provider to demo-standard and reloads so the Kiosk option isn't disabled by the "requires POS" gate.

Valid values: demo-minimal, demo-standard, or demo-full. Any other value is ignored (the bypass only triggers for keys in DEMO_POS_CHANNELS).

What It Does NOT Do ​

The bypass is intentionally minimal. It does not:

  • Run a discovery conversation or produce setup steps.
  • Require or check a branding profile or business profile.
  • Auto-create a location, menu, or any payment configuration.
  • Appear in the Guided Setup POS selection grid.
  • Touch the backend in any way (no setup-status flags are set by it).

The previous version of this doc described a discovery-questions flow, per-channel setup-step lists, a branding prerequisite, auto-created demo location/menu/payment, and a /dashboard?demo=standard URL trigger. None of those exist in the code — they have been removed as fabricated. Real onboarding (for real providers) is documented in the Guided Setup feature.

Real Onboarding (for context) ​

Actual merchant onboarding does not use demo channels. It runs through Guided Setup with a real POS provider and real setup pages, for example:

  • Store Branding → /settings/brand (Settings → Brand)
  • Business profile (checklist step "Set up Business Profile") → /settings/payments (Settings → Business profile); billing is its Billing tab (/settings/billing forwards there)
  • Locations → /settings/locations
  • Online Ordering → /online/online-ordering

Completion is auto-detected by the backend GET /api/back-office/setup-status endpoint, not simulated. See the Guided Setup feature doc for the authoritative flow.

Playwright Usage ​

typescript
// Inject the demo POS channel so POS-gated features are reachable in tests.
// Only works when isTestEnv is true (the build environment is not production/staging).
await page.goto('/device-management/devices')
await page.evaluate(() =>
  localStorage.setItem('qa_demo_provider', 'demo-standard')
)
await page.reload()
// Kiosk / post-POS features are now accessible without a real POS.

Not Verified Here ​

The following framing from the original doc could not be confirmed against back-office or backend code and should be treated as not verified here:

  • That demo-standard "simulates a Mpluskassa/Shopcaisse-like" onboarding flow.
  • Any sales/demo-environment or staging-deployment process narrative around demo merchants.
  • Any distinction in feature scope between demo-minimal, demo-standard, and demo-full.