changes

2026-09-02 10:49:46 +05:30
parent 1e3fe88e87
commit c0d39e550d
8 changed files with 463 additions and 25 deletions
--- a/init/nearledb/02-seed.sql
+++ b/init/nearledb/02-seed.sql
@@ -0,0 +1,164 @@
+-- A synthetic shop to develop against.
+--
+-- INVENTED DATA, and that is the point. Copying rows out of production to get a
+-- working local console puts real customers, real orders and real (cleartext)
+-- passwords on a laptop — so this file makes up a merchant instead, which means
+-- it can be committed, shared, and reset without anybody thinking about what is
+-- in it.
+--
+-- Everything uses ids from 9000 up, well clear of anything real, so a local
+-- database that has also had production rows loaded into it will not collide.
+--
+-- What it gives you:
+--
+--   * a complete merchant (9001 Testmart) — profile filled in, so the setup
+--     walkthrough shows it finished
+--   * an INCOMPLETE merchant (9002 Halfmart) with `categoryid = 0` — the exact
+--     shape that broke `gettenantinfo` and made the profile step impossible to
+--     finish. Worth keeping as a permanent regression fixture.
+--   * two branches, so the "All branches" tenant-wide read has something to
+--     aggregate and cannot silently show one outlet
+--   * one account per role, so every workspace can be signed into
+--   * products in each of the three app-visibility states — on sale, no stock,
+--     no price — because those three are what most console bugs turn out to be
+--
+-- Passwords are the literal string below. Fiesta compares passwords in clear,
+-- which is a real problem in production and simply a fact here.
+
+BEGIN;
+
+-- ── Masters the tenant joins hang off ───────────────────────────────────────
+INSERT INTO app_location (applocationid, locationname, latitude, longitude, radius)
+VALUES (9001, 'Testville', '11.0168', '76.9558', 25000)
+ON CONFLICT (applocationid) DO NOTHING;
+
+INSERT INTO app_category (categoryid, categoryname)
+VALUES (9001, 'Grocery')
+ON CONFLICT (categoryid) DO NOTHING;
+
+-- ── Merchant one: complete ──────────────────────────────────────────────────
+INSERT INTO tenants (
+  tenantid, tenantname, companyname, configid, categoryid, applocationid,
+  primaryemail, primarycontact, address, suburb, city, state, postcode,
+  latitude, longitude, tenantimage, tenantinfo, licenseno, registrationno,
+  minorder, approved, status
+) VALUES (
+  9001, 'Testmart', 'Testmart Retail', 1, 9001, 9001,
+  'owner@testmart.invalid', '9000000001', '1 Test Street', 'Testville', 'Coimbatore',
+  'Tamil Nadu', '641001', '11.0168', '76.9558',
+  'https://placehold.co/200x200?text=Testmart', 'Daily needs and fresh produce.',
+  '12345678901234', 'REG-TESTMART-1',
+  99, 1, 'Active'
+) ON CONFLICT (tenantid) DO NOTHING;
+
+-- ── Merchant two: the regression fixture ────────────────────────────────────
+--
+-- `categoryid = 0` matches no `app_category` row. Both master joins in
+-- GetTenantByID were INNER, so this tenant came back as an all-zero record —
+-- the console showed an empty profile form over a real business, and the setup
+-- walkthrough's first step could never complete. Four of two hundred live
+-- tenants are in this state. Keep it: it is the cheapest possible guard against
+-- that join going back.
+INSERT INTO tenants (
+  tenantid, tenantname, configid, categoryid, applocationid,
+  primaryemail, primarycontact, address, city, state, postcode, approved, status
+) VALUES (
+  9002, 'Halfmart', 1, 0, 9001,
+  'owner@halfmart.invalid', '9000000002', '2 Test Street', 'Coimbatore',
+  'Tamil Nadu', '641002', 1, 'Active'
+) ON CONFLICT (tenantid) DO NOTHING;
+
+-- ── Two branches, so tenant-wide reads have something to aggregate ──────────
+INSERT INTO tenantlocations (
+  locationid, tenantid, locationname, email, contactno, address, suburb, city,
+  state, postcode, latitude, longitude, opentime, closetime, applocationid,
+  deliveryradius, deliverymins, status
+) VALUES
+  (9101, 9001, 'Testmart Main', 'main@testmart.invalid', '9000000011',
+   '1 Test Street', 'Testville', 'Coimbatore', 'Tamil Nadu', '641001',
+   '11.0168', '76.9558', '08:00', '22:00', 9001, 5000, 30, 'Active'),
+  (9102, 9001, 'Testmart North', 'north@testmart.invalid', '9000000012',
+   '9 North Road', 'Northville', 'Coimbatore', 'Tamil Nadu', '641004',
+   '11.0500', '76.9600', '09:00', '21:00', 9001, 5000, 30, 'Active'),
+  (9103, 9002, 'Halfmart Main', 'main@halfmart.invalid', '9000000021',
+   '2 Test Street', 'Testville', 'Coimbatore', 'Tamil Nadu', '641002',
+   '11.0170', '76.9560', '08:00', '22:00', 9001, 5000, 30, 'Active')
+ON CONFLICT (locationid) DO NOTHING;
+
+-- ── One account per role ────────────────────────────────────────────────────
+--
+-- `authname` and `configid` are both set on every row. Login is
+-- `WHERE authname = ? AND configid = ?` and never looks at the email column, so
+-- an account missing either is created, listed, and refused at the sign-in
+-- screen. That was a real bug; these rows are what it looks like done right.
+--
+-- roleid decides the workspace: 1 and 3 reach Store Admin, everything else is a
+-- branch user. 7 and 8 are till accounts and are excluded from every
+-- back-office query by the backend itself.
+INSERT INTO app_users (
+  userid, authname, firstname, lastname, email, dialcode, contactno,
+  configid, roleid, password, tenantid, locationid, applocationid,
+  status, issuperadmin
+) VALUES
+  (9201, 'admin@testmart.invalid', 'Tessa', 'Admin', 'admin@testmart.invalid',
+   '+91', '9000000101', 1, 3, 'localdev', 9001, 9101, 9001, 'Active', false),
+  (9202, 'main@testmart.invalid', 'Mani', 'Manager', 'main@testmart.invalid',
+   '+91', '9000000102', 1, 4, 'localdev', 9001, 9101, 9001, 'Active', false),
+  -- Hired, not yet placed. `locationid = 0` is the state the people screen
+  -- exists to resolve, and it was invisible until GetStaffs stopped INNER
+  -- JOINing tenantlocations.
+  (9203, 'newhire@testmart.invalid', 'Nila', 'Newhire', 'newhire@testmart.invalid',
+   '+91', '9000000103', 1, 4, 'localdev', 9001, 0, 9001, 'Active', false),
+  (9204, 'super@testmart.invalid', 'Sup', 'Ervisor', 'super@testmart.invalid',
+   '+91', '9000000104', 1, 7, 'localdev', 9001, 9101, 9001, 'Active', false),
+  (9205, 'cash@testmart.invalid', 'Cash', 'Ier', 'cash@testmart.invalid',
+   '+91', '9000000105', 1, 8, 'localdev', 9001, 9101, 9001, 'Active', false),
+  (9206, 'admin@halfmart.invalid', 'Hal', 'Admin', 'admin@halfmart.invalid',
+   '+91', '9000000201', 1, 3, 'localdev', 9002, 9103, 9001, 'Active', false)
+ON CONFLICT (userid) DO NOTHING;
+
+-- ── Products, in each of the three visibility states ────────────────────────
+--
+-- categoryid 2 is what the customer app browses. A product filed anywhere else
+-- is invisible to shoppers however well priced and stocked, which is the single
+-- most common cause of "it is not showing in the app".
+INSERT INTO products (
+  productid, tenantid, categoryid, subcategoryid, productname, productbrand,
+  productsku, productunit, productcost, retailprice, taxpercent, approve,
+  productimage, productdesc
+) VALUES
+  (9301, 9001, 2, 0, 'Test Rice 5kg', 'Testbrand', 'TM-RICE-5K', '5kg',
+   320, 395, 5, 1, 'https://placehold.co/120x120?text=Rice', 'Everyday long grain'),
+  (9302, 9001, 2, 0, 'Test Oil 1L', 'Testbrand', 'TM-OIL-1L', '1L',
+   150, 198, 5, 1, 'https://placehold.co/120x120?text=Oil', 'Cooking oil'),
+  (9303, 9001, 2, 0, 'Test Biscuits 100g', 'Testbrand', 'TM-BISC-100', '100g',
+   18, 25, 12, 1, 'https://placehold.co/120x120?text=Biscuits', 'Sweet biscuits'),
+  -- Filed under no category: priced, released and stocked below, and still
+  -- invisible to the app. The state that catches everybody.
+  (9304, 9001, 0, 0, 'Test Uncategorised', 'Testbrand', 'TM-UNCAT', '1pc',
+   10, 15, 0, 1, 'https://placehold.co/120x120?text=Uncat', 'No category on purpose')
+ON CONFLICT (productid) DO NOTHING;
+
+-- price + publishedat = priced and released. Both are needed: a product with
+-- one and not the other looks identical on the shelf and cannot be sold.
+INSERT INTO productlocations (
+  productlocationid, tenantid, locationid, productid, price, status, publishedat
+) VALUES
+  (9401, 9001, 9101, 9301, 395, 'Active', NOW()),   -- on sale
+  (9402, 9001, 9101, 9302, 198, 'Active', NOW()),   -- released, no stock below
+  (9403, 9001, 9101, 9303,   0, 'Active', NULL),    -- no price, not released
+  (9404, 9001, 9101, 9304,  15, 'Active', NOW()),   -- everything but a category
+  (9405, 9001, 9102, 9301, 395, 'Active', NOW())    -- same product, second branch
+ON CONFLICT (productlocationid) DO NOTHING;
+
+-- Stock is SUM(in) - SUM(out) per outlet, never a stored figure.
+INSERT INTO productstocks (
+  productstockid, tenantid, locationid, productid, stockdate, stocktype, quantity, status
+) VALUES
+  (9501, 9001, 9101, 9301, NOW(), 'in',  40, 'Active'),
+  (9502, 9001, 9101, 9301, NOW(), 'out',  5, 'Active'),  -- balance 35
+  (9503, 9001, 9101, 9304, NOW(), 'in',  10, 'Active'),
+  (9504, 9001, 9102, 9301, NOW(), 'in',  12, 'Active')
+ON CONFLICT (productstockid) DO NOTHING;
+
+COMMIT;