toga-ai 1.0.759 → 1.0.761

package/knowledge/1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md

@@ -202,6 +202,43 @@ Prudential-EDI, S&P Global**.
 - **Lesson:** any `sync*FromNetsuite()` that takes the record `&$byReference` and refetches must have
   its fetch-by-id shim carry **every** field the caller reads afterward — `lastModifiedDate` first.
 
+### ⚠ …but the by-reference shim wrote the cursor on the WRONG CLOCK → ITEM_RECEIPTS + ITEM_FULFILLMENTS re-matched forever (found + fixed 2026-09-03, NYCHH prod)
+
+A follow-on to the by-reference fix directly above. Once the two shims carried a `lastModifiedDate`
+again, the sections still could **not advance** — the value was in the **wrong timezone**, so
+`lastmodifieddate > cursor` re-matched the **same record every run** (an infinite loop, no crash).
+
+- **Root cause — two clocks.** The prior fix set `fetchItemFulfillmentById` / `fetchItemReceiptById`'s
+  `->lastModifiedDate` from the **REST record GET**, which returns **UTC** (e.g. `2024-08-06T14:45:00Z`).
+  `common_sync_togasupply.php` then `date()`-formats it in the script timezone **America/Chicago** →
+  `2024-08-06 09:45:00`, and stores that as the cursor. But the LIST fetch's `WHERE`
+  (`App_Api_Netsuite_Rest::listItem*`) compares `lastmodifieddate` via SuiteQL
+  `TO_CHAR(lastmodifieddate,'YYYY-MM-DD HH24:MI:SS')`, which is the **NetSuite account timezone =
+  Eastern** → `2024-08-06 10:45:16`. So the cursor was written **~1 hour behind** the clock the fetch
+  reads → `lastmodifieddate > cursor` was always still true for the record just processed → it was
+  re-fetched and re-processed forever and the watermark never moved.
+- **Proven on NYCHH prod** (item receipt internalId `4953915`): REST GET `lastModifiedDate`
+  `2024-08-06T14:45:00Z` (UTC) · SuiteQL `2024-08-06 10:45:16` (Eastern) · stored cursor
+  `2024-08-06 09:45:00` (Chicago). ITEM_RECEIPTS was jammed on it; because that heavy receipt (nested
+  PO→SO reconcile) runs **before** fulfillments and starved the run, ITEM_FULFILLMENTS' window kept
+  collapsing to 6s and never grew to clear the empty gap to its first real record (2025-01-06; 1,294
+  NYCHH fulfillments waited after 2025-01-01).
+- **INVENTORY_ADJUSTMENTS was NOT stuck** — `fetchInventoryAdjustmentById` already reads
+  `lastmodifieddate` from SuiteQL `TO_CHAR` (the right clock), so it advanced normally. **That is the
+  correct pattern**; the other two shims did not follow it.
+- **Fix (library only, `php -l` clean, fail-loud preserved):** in `library/app/api/netsuite/rest.php`,
+  `fetchItemFulfillmentById` (~L2093) and `fetchItemReceiptById` (~L2254) now set
+  `$shim->lastModifiedDate` from a SuiteQL
+  `SELECT TO_CHAR(lastmodifieddate,'YYYY-MM-DD HH24:MI:SS') AS lastmodifieddate FROM transaction WHERE id = $id`
+  (Eastern) — matching `fetchInventoryAdjustmentById` — **instead of** the REST header's UTC
+  `$header->lastModifiedDate`. No shim reads the REST/UTC `lastModifiedDate` anymore. No worker change,
+  no SQL. After deploy the two sections resume and backfill on their own (idempotent).
+- **Lesson:** the per-record cursor value MUST be written in the **same timezone the fetch `WHERE`
+  compares against** — SuiteQL account time (Eastern), never the REST record GET's UTC
+  `lastModifiedDate`. A cursor even an hour behind the fetch clock re-matches the same record forever.
+  This is the same SuiteQL-vs-REST clock trap as the date-only-format bug above — see the
+  [SuiteQL/REST shim doc](../../library/features/netsuite-suiteql-rest-shim.md).
+
 ### ⚠ Per-record isolation is SECTION-SPECIFIC — and SALES_ORDERS has NONE (corrected 2026-08-17)
 
 Whether a bad record is "stepped over" or freezes the section depends entirely on whether **that
@@ -1175,6 +1212,15 @@ the code deploy).
 
 ## Change history
 
+- 2026-09-03 — **By-reference shim wrote the cursor on the WRONG CLOCK → ITEM_RECEIPTS + ITEM_FULFILLMENTS
+  re-matched the same record forever (fixed, `library` only).** Follow-on to the same-day by-reference
+  fix below: the shims set `lastModifiedDate` from the REST GET (UTC), `date()`-formatted in
+  America/Chicago, but the LIST `WHERE` compares SuiteQL `TO_CHAR(lastmodifieddate)` in the NetSuite
+  account tz (Eastern), so the cursor sat ~1h behind the fetch clock and `lastmodifieddate > cursor`
+  always re-matched — infinite loop, no crash. `fetchItemFulfillmentById`/`fetchItemReceiptById`
+  (`rest.php` ~L2093/~L2254) now read `lastmodifieddate` from SuiteQL `TO_CHAR` (Eastern), matching
+  `fetchInventoryAdjustmentById` (already correct). Proven on NYCHH prod (item receipt 4953915). No
+  worker/SQL change; sections self-backfill after deploy. (jcardinal)
 - 2026-09-03 — **By-reference refetch dropped `lastModifiedDate` → ITEM_FULFILLMENTS + INVENTORY_ADJUSTMENTS
   froze (fixed, `library` only).** GroWrk's ITEM_FULFILLMENTS was re-throwing every 5 min since the
   2026-09-02 per-record cursor deploy (`Undefined property: stdClass::$lastModifiedDate` at

package/knowledge/2.0/apps/_underscore/features/tableview-joins.md

@@ -6,7 +6,7 @@ project: _Underscore
 client: shared
 type: feature
 status: active
-updated: 2026-09-02
+updated: 2026-09-03
 owners: [bala, apeterson, jcardinal]
 files:
   - _underscore/Model/Client/TableView.php
@@ -28,6 +28,7 @@ related:
   - ../../../../clients/compass-canada/features/item-fulfillment-tableviews.md
   - ./acl-permission-chain.md
   - ../../toga25-supply/features/transfer-orders-page.md
+  - ../../toga25-supply/features/record-modals-and-nested-tables.md
 ---
 
 ## Summary
@@ -134,6 +135,36 @@ For NYCHH both hops are **100% populated** (PO items 1129/1129, VendorItems 2414
 **INNER** — no empty-grid risk (third failure mode above). Verify FK population per tenant first: a
 tenant with sparse `vendorItemId` would need LEFT OUTER or would empty the grid.
 
+### A dropped FILTER-ONLY join must be re-added when a row-filter still targets that table
+
+The rebase above **dropped** the old SalesOrders→bridge→PurchaseOrders chain (join ids 123/124/141)
+because those joins showed **no column** — they only filtered rows. But a filter-only join is still
+needed if something still filters on that table. NYCHH's Inventory "Items by Customer POs" grouping
+drills into `items-for-purchase-orders` with an `additionalDataSlug` that binds a
+`(PurchaseOrders.uuid:eq:...)` where clause (see
+[record-modals-and-nested-tables](../../toga25-supply/features/record-modals-and-nested-tables.md),
+Pattern 5, and
+[tableview-apiwhereclause-row-filtering](../../api2/features/tableview-apiwhereclause-row-filtering.md)).
+After the rebase the view no longer joined PurchaseOrders, so that filter failed with **error
+3L-2492**.
+
+Fix (confirmed working NYCHH 2026-09-03): **INSERT one filter-only `TableViewJoins` row** on the
+`items-for-purchase-orders` view re-adding a real PurchaseOrders join — no column hangs off it:
+
+- `joinRecordId = 17` (PurchaseOrders), `joinOnRecordFieldId = 81` (`PurchaseOrders.id`) as onA,
+  `parentRecordFieldId = 90` (`PurchaseOrderItems.purchaseOrderId`) as onB.
+- `type INNER` — `purchaseOrderId` is always populated on PO items, so no empty-grid risk (third mode
+  above). `sortOrder 7` (after the existing 1–6).
+- **No ACL row needed** if PurchaseOrders already has read grants for the caller's roles: NYCHH's
+  record 17 already had Base(1)/Developer(2)/API(3), so the ACL-INNER-JOIN joins query keeps it.
+- Idempotent: key to the view by `TableViews.slug` (id-agnostic) with a fixed uuid and a `NOT EXISTS`
+  guard on `(tableViewId, joinRecordId=17)`. Core ids 17/81/90 verified stable/identical across prod
+  and client-sandbox.
+
+**Both env states were verified rebased** (prod AND client-sandbox: view 16 at base recordId 18 with
+no PurchaseOrders join) — the earlier "rebase is prod-only, not on client-sandbox" note is now stale.
+Applied to client-sandbox then prod (Client_Nychh).
+
 Core ids for this conversion (verified prod 2026-09-02, identical across clients/envs): **Records** —
 sales-order-items 15, purchase-order-items 18, vendor-items 19, items 21; item-level SO/PO bridges
 289 (downstream) / 290 (upstream). **RecordFields** — `PurchaseOrderItems.quantity` 94,
@@ -316,6 +347,13 @@ Core-level reference ids used (identical across all clients and environments): *
 
 ## Change history
 
+- 2026-09-03 — Added the **filter-only join counterpart** to the PO-items rebase: dropping a
+  column-less join that only *filtered* rows (SalesOrders→bridge→PurchaseOrders, ids 123/124/141)
+  breaks any row-filter still targeting that table. NYCHH's `items-for-purchase-orders`
+  `(PurchaseOrders.uuid:eq:...)` filter errored **3L-2492** post-rebase; fix is one INNER filter-only
+  PurchaseOrders join (joinRecordId 17, onA `PurchaseOrders.id` 81, onB `PurchaseOrderItems.purchaseOrderId`
+  90, sortOrder 7, no column, no new ACL). Confirmed working; both prod and client-sandbox verified
+  rebased (the prior "prod-only" note is stale). (jcardinal)
 - 2026-09-02 — Documented the **sales-order-item → purchase-order-item view conversion**: it needs an
   extra **VendorItems** hop because `PurchaseOrderItems` has no `itemId` (catalog reached via
   `vendorItemId → VendorItems (record 19) → itemId → Items`), unlike `SalesOrderItems` which joins

package/knowledge/2.0/apps/toga25-supply/features/record-modals-and-nested-tables.md

@@ -6,8 +6,8 @@ project: TOGa 2.5 Supply
 client: shared
 type: feature
 status: active
-updated: 2026-09-02
-owners: [apeterson, tcox]
+updated: 2026-09-03
+owners: [apeterson, tcox, jcardinal]
 files:
   - toga25-supply/src/pages/SalesOrders/view/SalesOrderRecordModalLayout/hooks/usePurchaseOrderDetails.ts
   - toga25-supply/src/pages/SalesOrders/view/SalesOrderRecordModalLayout/viewModel/useSalesOrderRecordModalLayoutModel.tsx
@@ -127,6 +127,18 @@ level. Each level fetches its own meta + data and renders a `GenericTableLayout`
 
 `additionalData` is produced per-level by callbacks (the WHERE-filter shape from Pattern 4). Each
 level runs its own `useServerTableUrlState` and strips its own slug key, isolating URL state.
+
+> **The FE APPENDS `.uuid` to a swap level's `additionalDataSlug` itself — so the stored surface
+> value must be the BARE table name (`PurchaseOrders`), never `<Table>.uuid`.** The grouping config
+> lives on `Core.SurfaceElements.config` (`inventory-list-groupings`, e.g. element key `posByItems`,
+> in `$.levels[N].additionalDataSlug`). If you store `PurchaseOrders.uuid` there, the FE produces a
+> **doubled** where clause `(PurchaseOrders.uuid.uuid:like:...)` and the filter never binds. Fix the
+> stored value to just `PurchaseOrders` (JSON_SET keyed by `Surfaces.slug` + `config.key`, guarded to
+> the stale value so it is re-runnable — id/uuid-agnostic because ids differ per env). Confirmed on
+> NYCHH 2026-09-03: this Core row is all-client (no NYCHH SurfaceOverride), and its old
+> `SalesOrders.uuid` was already wrong for a child view named `items-for-purchase-orders`. Sibling
+> element `itemsByPOs` (view `purchase-orders_items`) still carries the stale `SalesOrders.uuid` —
+> likely the same bug, not yet fixed.
 A page-level `pageMeta` (from `useFetchPageMeta`) flows down for field-label overrides. The page
 view model builds `TableLevel[]` arrays, picks the active one via a URL param, and passes `levels`
 to `GenericNestedTables` with `key={activeGrouping.key}` to force remount and avoid stale state.
@@ -274,6 +286,12 @@ Scaffold per the `ItemRecordModalLayout` pattern (`src/layout/ItemRecordModalLay
   [Transfer Orders page](transfer-orders-page.md).
 
 ## Change history
+- 2026-09-03 — Documented that the FE **appends `.uuid`** to a `GenericNestedTables` swap level's
+  `additionalDataSlug`, so the stored `Core.SurfaceElements.config` value must be the **bare table
+  name** (`PurchaseOrders`), not `<Table>.uuid` — a `.uuid` in the stored value produces a doubled
+  `(PurchaseOrders.uuid.uuid:like:...)` where clause and the filter never binds. Found fixing the
+  NYCHH Inventory "Group: Items by Customer POs" grouping (`inventory-list-groupings`, element
+  `posByItems`); sibling `itemsByPOs` still stale. (jcardinal)
 - 2026-09-02 — Fixed the approve/deny modal's Submit/Cancel row being cut off by a long "Reason for
   Request" (found in testing by Skyler; approach agreed with David — grow the height a little, scroll
   when it is very long). The single-action dialog is now taller but viewport-capped, and its action row

package/knowledge/clients/nychh/profile.md

@@ -18,7 +18,7 @@ project: _Underscore
 client: nychh
 type: profile
 status: active
-updated: 2026-09-02
+updated: 2026-09-03
 owners: ["jcardinal", "apeterson", "bala", "akhokhani"]
 files:
   - dbchanges2/Client_Nychh/2026-09-02a - TransferOrderNetsuitePushInterceptor.sql
@@ -97,15 +97,32 @@ table views. Client-specific DB change-sets live in `dbchanges2/Client_Nychh/`.
   items 1129/1129, VendorItems 2414/2414) so both stay INNER. Seeds Developer-role record grants for
   records 18 and 19 (both had only Base+API) plus Developer read on `PurchaseOrderItems.quantity`
   (field 94); roles resolved by name, uuid-keyed, idempotent. Mechanism:
-  [tableview-joins](../../2.0/apps/_underscore/features/tableview-joins.md). 🚨 **Applied to PROD
-  only so far** (view 16 rebased, chain returns 1131 rows) — **NOT run on client-sandbox** (still the
-  old sales-order-items version); the parent 2026-08-31a went to prod + client-sandbox, this one is
-  prod-only. **OPEN:** the parent `purchase-orders` view filters to vendor 172 (`apiWhereClause
+  [tableview-joins](../../2.0/apps/_underscore/features/tableview-joins.md). **Applied to prod AND
+  client-sandbox** — both verified rebased 2026-09-03 (view 16 at base recordId 18, no PurchaseOrders
+  join). An earlier note here said this rebase was prod-only / not on client-sandbox; that is **stale**
+  — client-sandbox is also rebased. **OPEN:** the parent `purchase-orders` view filters to vendor 172
+  (`apiWhereClause
   (vendorId:eq:172)`); this item view has no `apiWhereClause`, so it lists items for all POs — left
   unfiltered (mirrors prior state), flagged as a decision for the dev. A "3L-2250" error reported
   right after this deploy was **unrelated** — prod `Logs.Issue` reference **3L** is a Prudential ASN
   error (`Client_Prudential.AdvanceShippingNoticeUnits` doesn't exist); the suffix is the occurrence
   count (3L, occurrence 2250).
+- **"Group: Items by Customer POs" grouping fixed to drill into PO items (2026-09-03).** After the
+  `items-for-purchase-orders` view was rebased to PO-items, the Inventory groupings surface
+  (`inventory-list-groupings`, element `posByItems`) was broken. Two fixes, both applied to
+  client-sandbox then prod (confirmed working):
+  1. **Stale filter slug** — the swap level's `additionalDataSlug` was `SalesOrders.uuid`; changed to
+     `PurchaseOrders`. The FE **appends `.uuid` itself**, so the stored value must be the bare table
+     name — `PurchaseOrders.uuid` produced a doubled `(PurchaseOrders.uuid.uuid:like:...)` clause.
+     This config is on `Core.SurfaceElements.config` (all-client, no NYCHH override); JSON_SET keyed by
+     `Surfaces.slug` + `config.key`, guarded/re-runnable. Sibling `itemsByPOs` still carries the stale
+     `SalesOrders.uuid` — likely the same bug, **not yet fixed**.
+  2. **Missing join** — the `(PurchaseOrders.uuid:eq:...)` filter errored **3L-2492** because the
+     rebase dropped the old SalesOrders→PurchaseOrders filter chain and the view no longer joined
+     PurchaseOrders. Added one filter-only INNER `TableViewJoins` row (joinRecordId 17, onA
+     `PurchaseOrders.id` 81, onB `PurchaseOrderItems.purchaseOrderId` 90, sortOrder 7, no column). No
+     new ACL — record 17 already has Base/Developer/API read. Mechanism:
+     [tableview-joins](../../2.0/apps/_underscore/features/tableview-joins.md).
 - **`inventory_units` table view carries item detail as of 2026-08-18** — Part Number, Manufacturer
   and Item Description sit directly after Asset Tag, reached through a **chained** Units → Items →
   Manufacturers join (`dbchanges2/Client_Nychh/2026-08-18 - InventoryUnitsItemColumns.sql`, identical

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "toga-ai",
-  "version": "1.0.759",
+  "version": "1.0.761",
   "description": "TOGA Technology Team Claude Knowledge System — shared AI coding harness with skills, knowledge base CLI, and project installer for Claude Code.",
   "keywords": [
     "claude",