Loading uses the standard white bottomsheet/modal; once Paystack Inline is
ready the host shell goes transparent so only Paystack's card shows on the
backdrop — no oversized second white frame on Merchant/Give/etc.
When Paystack Inline is ready: widen desktop panel for channel sidebar, collapse
to a minimal header, hide footer trust line, and re-pin the checkout iframe to
the sheet body so it does not read as a second modal on top of Ladill chrome.
Redirect Paystack iframes into the bottomsheet/modal body (where the spinner
is) instead of allowing a second full-viewport Paystack modal on top. Hide
Paystack background dimmer; keep Ladill header/close chrome.
Pre-set allow=fullscreen on Paystack iframes before navigation (createElement
hook + MutationObserver on allow/src/id), re-apply if Paystack overwrites
allow, and send Permissions-Policy HTTP headers so checkout.paystack.com can
use fullscreen inside the in-app sheet.
Pass access_code into the payment sheet, launch Paystack Inline only,
and hide Ladill chrome after Inline loads so register Card/MoMo shows
a single payment interface.
Paystack blocks iframes, so checkout uses a popup beside the sheet/modal chrome. Opening about:blank on the user tap keeps that window from being blocked after the async initiate response.
Paystack checkout.paystack.com returns X-Frame-Options: SAMEORIGIN, so the shared sheet opened empty. Keep mobile sheet/desktop modal chrome, launch checkout in a named window with a Continue CTA fallback, and escape payment-return via window.opener or top.
Replace ad-hoc demo-cashier-{id} accounts with DemoWorld staff who hold
a pos role, mirrored locally by email until SSO remaps to public_id.
Sales for the first named customers now use DemoWorld people (name +
phone) instead of generic "Cash Customer N" labels, and staff logins
skip the login reseed so mid-demo state survives.
Co-authored-by: Cursor <cursoragent@cursor.com>
Demo Free/Pro/Enterprise accounts wipe and reload sample data on
authorization-code SSO callbacks so every sales walkthrough starts clean.
Co-authored-by: Cursor <cursoragent@cursor.com>
Kitchen display devices open a full-screen KDS without staff login,
with feed/stream/bump over the device token. Shared kitchen board
logic is extracted so the signed-in Kitchen page stays in sync.
Register tills, customer displays, kitchen screens, printers, scanners,
and tablets per branch. Customer displays share the branch display token
and mark online when the public screen polls; stale devices go offline
on a schedule.
Implement the missing SettingsController::persistGateway method so merchant Paystack/Flutterwave/Hubtel keys can be saved, and cover create + keep-blank-secrets paths with tests.
Card/MoMo always initializes with the merchant email, and Paystack/Flutterwave/Hubtel open in-page (desktop modal, mobile bottomsheet) instead of a full redirect.
Co-authored-by: Cursor <cursoragent@cursor.com>
Embed branch list, switching, and team invites on the main settings page; dedicated routes redirect back with anchors.
Co-authored-by: Cursor <cursoragent@cursor.com>
Pro and Business users can manage branches, invite cashiers with branch assignment, and switch registers; sales and register flows respect acting location.
Co-authored-by: Cursor <cursoragent@cursor.com>
Per-location logo in settings with remove/replace support; receipt template reserves space at the top when a logo is set.
Co-authored-by: Cursor <cursoragent@cursor.com>
Register supports USB keyboard-wedge scanners with SKU lookup (local catalog
and CRM in retail mode). Sales get a thermal receipt print template (58/80mm)
with configurable header/footer, plus optional auto-print after cash sales.
Co-authored-by: Cursor <cursoragent@cursor.com>
Customers with large catalogs can upload a CSV instead of adding products one by
one. Mode-aware: restaurant imports into the local catalog (chunked INSERT,
categories resolved/created by name); retail batches to the CRM products/bulk
endpoint. Streamed parsing + batched writes handle thousands of rows in one
request. Includes a downloadable template, an Import button on both product
pages, and a skipped-rows report.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
InjectBootSplash middleware injects a full-screen loading splash — the app's
launcher icon (pulsing), an animated progress bar, and "Loading <app>…" — into
authenticated HTML pages, then fades it out on load. Shows once per browser
session (sessionStorage), so it masks the app's client-side boot without
flashing on every navigation. Self-branding from the app's own subdomain icon,
so the same partial/middleware drops into every Ladill app.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
On a sale's detail page, unpaid sales (retail or restaurant) can now be
cancelled or deleted:
- Cancel (pending only) marks it cancelled and frees its table / clears it from
the kitchen (PosSaleService::cancelSale).
- Delete removes the sale and cascades its lines, modifiers and payments, freeing
the table first (deleteSale). Paid sales are protected — they can't be deleted.
Status badge now distinguishes cancelled/failed. Covered by PosRestaurantTest.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Products are now mode-aware:
- Retail: the catalog lives in Ladill CRM. The Products page proxies CRUD to the
CRM products API (CrmClient gains product/create/update/delete), and the
register reads CRM products live; a sold line is stored as a name/price
snapshot (product_id null, since CRM products aren't local rows). Resilient —
the register shows an empty catalog if CRM is unreachable. CRM import is hidden
in Settings (not needed when reading live).
- Restaurant: unchanged — the local pos_products catalog keeps its POS-only depth
(category, kitchen station, course, modifier groups).
ProductController routes take a raw {product} id (CRM id in retail, local id in
restaurant). Suite green (17), covering both modes.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A segmented Retail | Restaurant control in the register header flips the
location's service_style in place (RegisterController@setMode → pos.mode.set).
Switching to restaurant lands on the Floor and reveals Floor/Kitchen/Menu in the
sidebar; switching to retail stays on the register. Covered by PosRestaurantTest.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Split bills (restaurant tickets):
- New pos_payments ledger; a tab is settled across one or more cash/Ladill Pay
payments. The ticket shows total / paid / balance, an amount field with Full /
½ / ⅓ / ¼ helpers, and the payments taken. Partial payments keep the tab open;
the sale finalises (and frees the table) only when the balance hits zero.
Pay splits get their own checkout + callback (pos.payments.callback).
Pipe online orders to the KDS:
- POST /api/kitchen/orders — a first-party, service-keyed ingest
(config pos.kitchen_api_keys, scoped by owner, idempotent by external_ref) that
creates a paid, already-fired ticket (order_type=online, lines source=online).
- The KDS feed is now payment-agnostic (any kitchen-active sale), so paid online
orders sit on the board next to dine-in tabs and bump the same way; they're
badged "online".
Schema additive: pos_payments, pos_sales.external_ref. Suite green (14).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The "links" slice — a guest scans a table's QR, browses the menu (with
modifiers), and submits an order that lands on that table's open tab and fires
straight to the Kitchen Display.
- Public, auth-free flow scoped by an unguessable table short_code:
GET /t/{code} (menu + client cart), POST /t/{code}/order (throttled),
GET /t/{code}/done. Orders open/append the table's dine-in tab, add lines as
source=guest, and send to the kitchen.
- Staff print a per-table QR (Settings → table → QR; renders client-side to the
public menu URL). short_code is generated lazily.
- Guest lines are badged on the ticket and the KDS so staff can tell them apart;
staff still settle the tab as usual (cash / Ladill Pay).
- Extracted PosSaleService::buildProductLine as the single product+modifier
price resolver, now shared by staff and guest ordering (client prices never
trusted).
Schema additive: pos_tables.short_code, pos_sale_lines.source. New
PosRestaurantTest covers the guest order firing to the kitchen; suite green (12).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Builds on Phase 1 with the menu structure restaurants need:
- Menu setup page (restaurant mode): categories, kitchen stations, and modifier
groups with options (price deltas).
- Products gain category, kitchen station, default course, and attached modifier
groups (managed on the product form).
- Ordering: the ticket groups the catalog by category and, when a product has
modifier groups, opens a picker (respects min/max select) for options + notes +
course before adding. Effective price = base + modifier deltas (resolved
server-side; client prices are never trusted).
- Fire-by-course: send the whole tab or just one course to the kitchen.
- KDS: filter by station; each item shows its station, course, modifiers and notes.
Schema additive (pos_categories, pos_stations, pos_modifier_groups, pos_modifiers,
product↔group pivot, pos_sale_line_modifiers; category/station/course columns on
products and lines). PosRestaurantTest covers modifiers, course and station routing;
suite green (11 passed).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Gated by a per-location service_style (retail | restaurant). Restaurant mode adds:
- Floor screen with tables (areas, seats, status) — tap a free table to open a
dine-in tab; takeaway/counter orders open from the same screen.
- Open tickets (tabs): a sale stays pending while items are added; lines persist
as you go (posTicket Alpine component posts each change to the server).
- Send-to-kitchen fires un-sent lines; a polling Kitchen Display (KDS) shows
active tickets and bumps items queued → preparing → ready → served.
- Settlement reuses the existing cash / Ladill Pay flow; paying closes the tab
and frees the table (PosSaleService::closeTicket, wired into both pay paths).
- Settings gains the mode toggle and a tables manager.
Schema is additive (new pos_tables; service_style on locations; order/kitchen
columns on sales + lines). Retail flow is untouched. Sidebar surfaces Floor +
Kitchen only in restaurant mode. New PosRestaurantTest covers the dine-in
lifecycle end to end; suite green (10 passed).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Finish removing the upstream platform fork: drop the Hosting/SSL/Domain
notification classes + their mail views, the email/mailbox/domains/hosting
view trees, the Mini/Afia/search/paystack partials and unused components, and
the now-orphan support helpers (DomainConfig, MailboxPricing,
ResellerClubLegacy), SmsService, and fork configs (afia, hosting, domain,
email, mailbox, qr, mail_brands, notifications, ...). Reparent the
notifications page off the hosting layout onto the POS app layout (it had
referenced undefined hosting./mini. routes). Computed the removable set from a
reachability scan of the POS view graph; kept views reference no removed
routes/services.
Branding: favicon now uses the updated favicon.ico (favicon.svg removed);
signed-out fallback logo points at the POS logo.
CRM import: constrain the catalogue pull to type=product so CRM services are
never imported as POS products (server-side filter + defensive client skip).
Test suite green (8 passed, 29 assertions); all routes resolve and every
remaining Blade compiles.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
POS was forked from Ladill Mini and carried Mini's entire mobile/QR
subsystem (API, QR codes, wallet, payments, push, Afia) which polluted the
ladill_pos schema with 8 unused tables and left ~half the test suite red.
Remove the dead subsystem: Api/Mini/Qr/Public/Search/WellKnown controllers,
Mini/Qr/Afia/Notifications services, the 8 unused models, QrCodePolicy,
Support/Qr + Support/Events, the two mini: scheduled commands, the Mini/QR
view trees, and their (failing) tests. Empty routes/api.php (POS is web-only)
and strip dead schedules from routes/console.php.
Keep QrTeamMember — it is the platform team-membership model that POS's
SetActingAccount middleware and SSO login depend on for multi-account access.
Also keep notifications + personal_access_tokens (used by POS).
Drops 7 migrations (qr product/settings, mini_payments, push tokens); the 8
orphan tables are dropped from the live ladill_pos DB separately. Test suite
is green (8 passed) and all routes resolve.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
isaacclad