0c407e5b273a86b67eec4b99a62f18fe156d115a
jupiter's getreportsummary took a locationid — per kitchen, per branch. That was the one report parameter with no Doormile equivalent, and for a food client with 23 kitchens it is the difference between one number and a usable report. GET /admin/reports?locationid= narrows every figure to one site GET /admin/reports now carries a by_location block GET /admin/locations/summary the standalone per-site table The filter alone would have been useless: pickuplocationid was null on every booking in the system, because the console sends a kitchen's address rather than its id. createExpressBooking now resolves the site itself — nearest stored location within 150m, falling back to an address match, nil when nothing matches confidently, since a wrong attribution silently moves orders between kitchens. An explicit pickuplocationid still wins. Bookings that named no site are reported as their own "Unattributed" row rather than dropped, so per-site rows add up to the summary total. Two fixes found while in here: - the payments join in the per-site query fanned out, counting a booking once per payment row; payments are now pre-aggregated per booking - by_rider was empty for every client login, which reads as "your riders did nothing". Riders are tenant-scoped now, so a client sees its own. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Description
No description provided
Languages
Go
94.8%
PLpgSQL
4%
Python
1.1%
Dockerfile
0.1%