The assign dropdown was empty on open. Two faults compounded: riders were
queried by tenantid, and the source list defaulted to a tab that could
never match.
/partners/getriders returns nothing for any tenant, because a rider record
leaves app_users.tenantid unset — riders belong to a partner and an
app-location. Scoping by applocationid returns them, so both Orders and
Deliveries now take the app-location from the rows they are showing and
fall back to the caller's.
The second fault was the "Store Fleet" default, which filtered for
partnerid === 0. Every on-duty rider has a partnerid, so the default tab
was always empty even once the query returned rows. It is now On Duty /
This Partner, the latter enabled only when the orders name a partner.
Dropped the getallusers?roleid=5 "own fleet" list it merged in. There is no
rider role: app_roles defines 1-6 as Super admin / Operations / Admin /
Manager per configid, and riders are identified by configid=6 inside
getriders. roleid=5 matched a single user with two deliveries in the
platform's history, while the users actually driving deliveries carry
roleid 0.
/partners/getriders is already a presence query rather than a roster — it
requires status Active, onduty=1 and a riderlog dated today with
logstatus=0 — so the list is riders working right now, and it carries the
userfcmtoken needed to reach them. Added a refetch so someone logging off
mid-shift drops out of the list.
Riders are now notified. The push runs after the write and is reported
separately: the deliveries are committed by then, so a failed push must not
read as a failed assignment, but it must still be visible because a rider
who was never told has work sitting unseen. A missing token is reported as
a rider with no device registered rather than as a transport failure, since
the remedy is different.
Deliveries gains the rider actions its placeholder promised: change rider,
notify, and send-cancellation carrying data.type=cancel. Change-rider is
offered only while a delivery is pending, accepted or arrived, because
reassigning resets orderstatus to pending and would otherwise rewind a
journey already completed.
reassignDeliveries was posting to /riders/reassigndeliveries, which is not
registered on the backend and answers 404. It had no callers, so the
failure had never been observed. It now goes through updatedelivery, one
call per delivery, tolerating partial failure.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The upload modal made the admin choose a branch, then generated and
validated the workbook against that choice. A merchant with several
outlets had to repeat the whole cycle per branch, and the picker
defaulted to the first outlet, so an admin who never opened it credited
the wrong store — the file and the selection agreed, so nothing flagged
it.
The sheet now carries tenantid, locationid and the store name as locked
columns on every row, and the row's own locationid routes its sale. One
file covers the whole business: fill in qtysold wherever something sold,
across as many branches as needed, and upload once. The picker is gone
from the admin surface entirely, and the store user's page keeps passing
its locationId, which pins the upload to that branch and rejects rows for
any other before they are even sent.
Bills are keyed on branch first and bill number second. Counter books at
different outlets restart numbering from 1, so a shared number is two
sales rather than a duplicate, and keying on the number alone would have
dropped the second one.
Because a single upload can now move stock at six outlets, one total is
no longer enough to check before committing: the preview gains a store
count, a per-store table of lines, units, amount and problems, and a
Store column on every row, and results name the branch on each bill.
Rows are ordered store then product with an Excel autofilter, so a
branch can isolate its own rows in a file spanning the business.
Verified end to end against a two-branch tenant sharing a product id
across both outlets: one upload deducted each branch independently, a
pinned upload refused the other branch's rows, and re-uploading deducted
nothing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Both the tenant onboarding and store/branch forms only had free-text
address fields with no coordinates captured, even though the backend
already accepts and stores latitude/longitude on both tenants and
tenantlocations. Wires in the existing keyless AddressAutocomplete
(Nominatim) component used by UsersPanel so picking an address also
geocodes it, and threads latitude/longitude through both create payloads.
Quick-import buttons hardcoded quantity:1, which the backend writes straight
to the stock ledger as an "in" entry — letting one order go through for a
product that was never actually stocked. Default to 0 instead, and fix a
fallback path that was silently coercing an explicit 0 back to 1 via `|| 1`.
The consumer app resolves a storefront by scanning a QR that encodes
{tenantid, locationid}. Store Onboarding was creating the location but never
surfacing its QR, so operators had to hunt for it later in the store detail
view. Now that the backend returns the created location's locationid in the
onboarding response, render the existing StoreQRView component directly in
the "Store Branch Active!" success panel (both onboarding UI variants) so the
printable QR is available the moment the branch is created.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
UsersPanel.tsx was sending configid: 15 (Staff) / 6 (Rider) when creating
users, copied from an unrelated Hasura "role config" convention. Every
login call (auth.ts) queries app_users with configid: 1, so any account
created with 15/6 could never be found on login and was stuck before it
even reached the password-setup step. Both create paths and the
CreateUserInput default now consistently use configid: 1.
Also fixes getRiderLogs() calling riders/getriderlogs, which 404s since
the backend only registers this route under /partners.
checkEmailRequest only checked whether the account existed, so a
first-login account (no password set yet) was still sent to the
normal "enter your password" screen before the backend revealed there
was no password to check against — only then did it route to the
create-password step. checkEmailRequest now detects the same
setup-required signal PasswordSetupRequiredError does and skips
straight to it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
AdminConsole renders the Tenant Onboarding form twice (embedded vs.
showHeader standalone) from two separate JSX blocks. The Primary
Outlet Name / Business Category fields added earlier only landed in
the embedded block, so the showHeader block SuperAdminPage actually
renders had no way to fill tenantForm.locationname — the required-
field check on submit failed unconditionally, no matter what was
filled in.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
catalogueApi.ts's fallback base URL ("/live/api/v1") was one path
segment short of where the routes actually live ("/live/api/v1/web"),
unlike every other service file's fallback. Any build without
VITE_FIESTA_URL set (it's gitignored, never committed) 404'd on every
catalogue call — browse, brands, categories, and import.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Accounts created by tenant/store onboarding (createtenantuser,
createtenantlocation) have no password set. Previously the login form
treated the backend's "please setup a password" response as a
successful login instead of prompting for one. Now auth.ts recognizes
it (PasswordSetupRequiredError) and LoginView routes to a create-
password step, then signs in immediately with the new password.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Header is position: fixed (h-16) and SuperAdminPage never offset its
content for that, so the onboarding form rendered underneath the
purple header bar. Add pt-16 to match how the rest of the app already
compensates for this same fixed header, and constrain content width
instead of stretching full-viewport.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
super_admin is now a real LoginRole, derived from the server's
issuperadmin flag (not a client-guessable roleid) — routes exclusively
to a new minimal SuperAdminPage, never the merchant console.
That page reuses the existing tenant/store/rider onboarding wizard
(AdminConsole) rather than duplicating it — its Tenant tab was already
calling the right composite endpoint but had nowhere to send location
data, and was never actually reachable from anywhere in the app. Now
it collects a primary outlet name + business category and sends a
nested tenantlocations object, so one submit provisions tenant +
active location + admin user instead of leaving the tenant
locationless. createTenantUser also moves off the mob API base onto
the web one, matching where this is actually called from.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Matches the backend: subcategory is no longer a required field in the
import modal (defaults to none/0 instead of blocking submission), and
the Category dropdown now comes from GET gettenantcategories (what
this tenant's own products actually use) instead of the global
categories list, which was missing categoryid 2 despite it being the
category tenant 1135 actually needs.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Removes InventoryView's broken duplicate Global Catalogue tab, which
misused createproductlocation with catalogue ids that never match real
product ids (imports silently failed to land) and showed fabricated
Math.random() pricing/ratings. "Import Product" now routes to the
already-correct CatalogueBrowser instead.
Also fixes catalogueApi's product_count field mismatch (brand chip
counts were always blank), a pagination bug that capped the catalogue
at 100 of ~237 products with no way to see the rest, and replaces
ImportProductModal's free-text category id input with a real dropdown
scoped to the tenant's own categories, filtering subcategories to match.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
