toga-ai 1.0.758 → 1.0.760

package/knowledge/1.0/apps/library/features/netsuite-suiteql-rest-shim.md

@@ -6,7 +6,7 @@ project: Library
 client: shared
 type: feature
 status: active
-updated: 2026-09-02
+updated: 2026-09-03
 owners: [dfranks, jcardinal, kyalamarthi]
 files:
   - library/app/api/netsuite/rest.php
@@ -197,6 +197,23 @@ Forecast2 tables already store.
   same underlying trap of reusing a sales-order-shaped assumption on a purchase order. Full
   engine-side impact + the tier-wide per-client backfill live on the
   [per-client-sync doc](../../worker/features/netsuite-togasupply-per-client-sync.md).
+- **⚠ The three detail-fetch shims were inconsistent about `->lastModifiedDate` — two omitted it and
+  froze their sections once a per-record cursor started reading it (fixed 2026-09-03).**
+  `fetchItemReceiptById` set `$shim->lastModifiedDate` from its REST header, but **`fetchItemFulfillmentById`
+  and `fetchInventoryAdjustmentById` did not** (and InventoryAdjustment's SuiteQL header didn't even SELECT
+  `lastmodifieddate`). This was harmless until the 2026-09-02 per-record resume cursor: because
+  `syncItemFulfillmentFromNetsuite(&$rec)` / `syncInventoryAdjustmentFromNetsuite(&$rec)` **reassign** their
+  by-reference record to the fetch-by-id shim, the engine's cursor PUT then read `$rec->lastModifiedDate` on
+  the **replaced** object → *Undefined property: stdClass::$lastModifiedDate* → `App_Error` `exit()` → the
+  ITEM_FULFILLMENTS / INVENTORY_ADJUSTMENTS section froze at `1-RUNNING`, window ÷3 (GroWrk's fulfillments
+  re-threw every 5 min; InvAdj was latent only because no client had processed one since the rename). **Fix
+  (`library` only, `php -l` clean):** `$shim->lastModifiedDate = (string)(...)` in **both** shims —
+  fulfillment from the REST header, inventory-adjustment after adding
+  `TO_CHAR(lastmodifieddate,'YYYY-MM-DD HH24:MI:SS') AS lastmodifieddate` to its header SELECT. **Lesson:
+  a fetch-by-id shim consumed as the replacement for a `&$byReference` record must carry every field the
+  caller reads after the call — `lastModifiedDate` first.** Sales orders / POs / invoices don't reassign, so
+  they were unaffected. Engine-side detail on the
+  [per-client-sync doc](../../worker/features/netsuite-togasupply-per-client-sync.md).
 - **A shim must produce the SOAP object's SHAPE, not just its scalar fields — an absent nested list
   crashes 1.0 (2026-08-29).** `fetchCustomerById()`'s `addressbookList` was where the AIG lookup phase
   crashed: a REST customer with no/odd address made the shim omit the nested `addressbook` structure the
@@ -290,6 +307,14 @@ None — uniform across clients (NetSuite is a single shared account).
 
 ## Change history
 
+- 2026-09-03 — Recorded that **`fetchItemFulfillmentById` and `fetchInventoryAdjustmentById` omitted
+  `->lastModifiedDate`** (unlike `fetchItemReceiptById`), which froze ITEM_FULFILLMENTS + INVENTORY_ADJUSTMENTS
+  once the 2026-09-02 per-record cursor read that field off the by-reference record these shims replace. GroWrk
+  was the reported alert; shared code so all four active togasupply clients (GroWrk, NYCHH, Prudential-EDI,
+  S&P Global) were affected. Fixed by setting `$shim->lastModifiedDate` in both shims (adding `lastmodifieddate`
+  to InventoryAdjustment's SuiteQL SELECT). `library`-only, `php -l` clean, no data lost, self-heals after
+  deploy. Lesson: a fetch-by-id shim used to replace a `&$byReference` record must carry every field the
+  caller reads afterward. (jcardinal)
 - 2026-09-02 — Recorded that **SuiteQL returns date columns in the account DISPLAY format (date-only
   `M/D/YYYY` here) unless wrapped in `TO_CHAR`** — a bare `lastmodifieddate` silently drops the time and
   is locale-dependent. This defeated the per-client sync's per-record resume cursor (stored `9/2/2026|id`,

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.758",
+  "version": "1.0.760",
   "description": "TOGA Technology Team Claude Knowledge System — shared AI coding harness with skills, knowledge base CLI, and project installer for Claude Code.",
   "keywords": [
     "claude",