abhishek
35250717fc
The separate Map tab is gone. "By rider" and "By store" now draw the map where the stops table was, so picking a rider from the rail shows their round on a map and picking a branch shows its day. A round and a shop's day are both shapes — where the work is, in what order, how far apart — and a table of addresses shows neither. You can read twenty rows and still not see that a rider crossed the city twice. Two views keep the table, on purpose: the waiting queue, whose rows are ticked to assign them (a checkbox cannot live on a map pin, and nothing there has been worked yet), and "By customer", where one customer's drops are all at one address. The map draws all three places a delivery has, not just the rider: shop a square, one per branch — pickuplat/pickuplon, 500/500 rows drop a circle per stop, by status — droplat/droplon, 500/500 rows rider a hollow ring — riderslat/riderslon, 461/500 and 324/500 Shop and drop are on every row, so the map is never empty on a day with work in it. The rider fix is real: on delivered rows it sits a median 134 m from the drop, a reading taken at the customer's door. The endpoints spell the columns differently — `pickuplon` on getdeliveries against `pickuplong` on getorders, one letter, and reading the wrong one puts every shop off the coast of Ghana. `droplat` is filled on deliveries and empty on orders. `coordOf` takes every spelling so a waiting order maps the same as a delivered one. Also fixes the rail itself: it named each group from its first stop's `ridername`, and that column holds a delivery status on more rows than a name for two riders in five. The board was listing a phantom rider called "delivered" carrying 100 of the day's stops, next to the real riders. Grouping was never wrong — that is on userid — only the label. `isRealName` now excludes the status vocabulary and both the rail and the map take the most common name that survives. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JYEsb8PNZ19G9R8gUjTU7n
Nearle Console
The new Nearle Daily retail operations console. Built against the existing Fiesta backend — the API is a fixed constraint, not something this repo changes.
Running it
npm install
npm run dev # http://localhost:3100
npm run typecheck # tsc --noEmit
npm run build # typecheck + production build
Port 3100, not 3000. The old console (
daily_merchant_web) runs its dev server on 3000.strictPortis on, so if 3100 is taken this fails loudly rather than silently moving — which is the failure that makes you think your changes did not land when you are actually looking at a different app.
In development Vite proxies /fiesta → https://fiesta.nearle.app. For a
deployed build set VITE_API_BASE (see .env.example).
Stack
| Layer | Choice |
|---|---|
| Build | Vite 8 |
| Language | TypeScript 7, strict, noUncheckedIndexedAccess. No .js/.jsx anywhere. |
| UI | React 19 + @astryxdesign/core |
| Theme | src/theme/nearle.ts, compiled to nearle.css |
| Routing | React Router 7, split per page |
| Server state | TanStack Query 5 |
| Icons | lucide-react |
| Spreadsheets | xlsx, loaded on demand |
What's built
Only the Nearle Admin workspace so far:
/nearle/stores— every tenant, branch counts, per-tenant performance/nearle/stores/:tenantId— one tenant's branches, orders and revenue/nearle/onboard/tenant— provision a merchant group/nearle/onboard/branch— commission an outlet with its delivery thresholds/nearle/catalogue— the global catalogue, plus both product-import paths
/admin/* (Store Admin) and /store/* (Store Manager) render a named
placeholder rather than a 404, so those roles land somewhere that explains
itself.
Things about the backend that shape this code
These are not bugs in this repo. They are the API's behaviour, and each one is worked around deliberately.
- No web authentication. The login endpoints return the user record and no
token; only
/v1/pos/*has middleware. So the session is that record, held insessionStorage.src/auth/session.tsis the only file that changes when tokens arrive. - Every list call needs a scoping id or it 400s. The IDOR pass added
controller-level guards. Query hooks are therefore
enabled-gated on the id and the id is part of the query key. - Roles are derived, not asserted.
issuperadminis checked beforeroleid, because the flag is server-derived and a roleid is not. Roleids 7 and 8 are till roles and never reach an admin workspace. POST /products/createtakes one product and returns no id. The controller passes the struct to the service by value, so GORM writes the generated id into a copy that is then discarded. The sheet importer therefore creates, then re-queries by SKU to resolve ids, then batches the location and stock writes. SeeimportSheetProductsinsrc/api/products.ts.- The two import paths are not symmetric. Catalogue import is one idempotent batch call. Sheet import is N creates with no dedupe on SKU, so re-uploading a file duplicates its products — the UI says so before the button.
- The global catalogue has a price range, not a price, and no mapping to a tenant's own categories. Category, subcategory, retail price, cost and tax are collected before an import can be enabled.
- POS endpoints take one required
locationid. There is no tenant-wide counter-sales call, so a multi-branch POS view fans out per branch.
The 30-second cadence
Online orders land when an order is placed; counter sales reach the console on a
30-second refetch; anything still sitting on an offline till has not arrived at
all. So any figure blending the two is eventually consistent, and the
<Freshness> component exists to say when a number was last true and how many
bills are still stranded. Polling is applied per query in src/queries/hooks.ts
rather than globally — a provisioning form has no business re-polling.
Design
The visual system is ported from KROW (which is built on Astryx too, so the
tokens are role-for-role comparable), with Nearle purple #662582 as the accent.
The ambient canvas in index.css — a fixed, viewport-wide horizontal gradient at
z-index: -1 — is the one piece of KROW that carries most of the character.
Radius, type scale and control heights are matched to KROW in
src/theme/nearle.ts, with the reasoning kept in comments.
Open: the dark-mode accent #B57FD0 was chosen for 5.41:1 contrast on
Astryx's dark surface and still needs brand-owner sign-off before dark mode
ships.