toga-ai 1.0.336 → 1.0.338

package/knowledge/2.0/apps/toga2-commerce/INDEX.md

@@ -6,7 +6,7 @@
 | [Cart Bundle Submission & the bundleUuid Identity Contract](features/cart-bundle-submission-and-identity.md) | How cart **bundles** (kits) are turned into `SalesOrderItems` when a cart is submitted or an existing order is edited, and the **identity-field contract** every | src/api/syncSalesOrderItemsFromLocalStorageCartToApi.ts, src/utils/formatSalesOrderBundlesFromApi.ts, src/stores/useCartStoreZu.ts, src/pages/OrderDetails/helpers/formatSalesOrderDataFromLocalStorage.ts, src/pages/OrderDetails/view/components/OrderItems.tsx |
 | [Cart Notification Emails — duplicate prevention](features/cart-notification-emails.md) | On the cart "Notifications" section a user can add CC email addresses to an order. | src/pages/Cart/CartPage.tsx, src/pages/Cart/view/cartForm/CartForm.tsx, src/stores/useEmailOptionsStore.ts, src/stores/useCartSalesQuoteZu.ts, src/pages/Cart/viewModel/FIELDS/*/*/*/CARTPAGE.ts |
 | [Cart Page — config-driven form architecture (current state + planned refactor)](features/cart-page-config-architecture.md) | The Cart page (`src/pages/Cart/`) is the most config-heavy page in `toga2-commerce`. | src/pages/Cart/CartPage.tsx, src/pages/Cart/view/cartForm/CartForm.tsx, src/pages/Cart/view/cartForm/CartFormSection.tsx, src/pages/Cart/view/cartForm/CartFormRenderer.tsx, src/pages/Cart/view/EditCart.tsx, src/pages/Cart/view/EditOrder.tsx, src/pages/Cart/viewModel/useEditOrderOrEditCartViewModel.ts, src/pages/Cart/viewModel/FIELDS/*/*/*/CARTPAGE.ts, src/hooks/useAssignClientFields.ts |
-| [Client Fields — per-tenant / language / role content & config](features/client-fields.md) | Almost no user-facing text, field layout, or page config is hard-coded in `toga2-commerce`. | src/fieldsConfig/index.ts, src/fieldsConfig/getClientLoginFields.ts, src/fieldsConfig/clientFields/COMPASS.json, src/fieldsConfig/clientFields/COMPASSCANADA.json, src/fieldsConfig/clientFields/QUAD.json, src/pages/Cart/api/CartApi.ts, src/hooks/useAssignClientFields.ts, src/hooks/useDynamicConditionalFieldOptions.ts, src/stores/useFieldsStore.ts, src/components/BaseDetailField/BaseDetailField.tsx |
+| [Client Fields — per-tenant / language / role content & config](features/client-fields.md) | Almost no user-facing text, field layout, or page config is hard-coded in `toga2-commerce`. | src/fieldsConfig/index.ts, src/fieldsConfig/getClientLoginFields.ts, src/fieldsConfig/clientFields/COMPASS.json, src/fieldsConfig/clientFields/COMPASSCANADA.json, src/fieldsConfig/clientFields/QUAD.json, src/pages/Cart/api/CartApi.ts, src/hooks/useAuthenticationFlow.ts, src/contexts/AuthContext.tsx, src/pages/Login/viewModel/useLoginPageViewModel.ts, src/hooks/useAssignClientFields.ts, src/hooks/useDynamicConditionalFieldOptions.ts, src/stores/useFieldsStore.ts, src/components/BaseDetailField/BaseDetailField.tsx |
 | [Config-Driven Expedited Shipping Gating (Cart)](features/expedited-shipping-gating.md) | On the toga2-commerce **Cart** page, expedited shipping options (**"2nd Day EOB"** and **"Next Day Air"**) are only offered in the *Shipping Method* dropdown wh | toga2-commerce/src/pages/Cart/helpers/shippingOptionGates.ts, toga2-commerce/src/pages/Cart/viewModel/FIELDS/shared/shippingOptionGates.ts, toga2-commerce/src/pages/Cart/view/cartForm/CartForm.tsx, toga2-commerce/src/pages/Cart/CartPage.tsx |
 | [Multi-Tenant Resolution & Theming](features/multi-tenant-theming.md) | `toga2-commerce` serves multiple clients from one codebase. | src/themeConfig/themes.json, src/themeConfig/ThemeContext.tsx, src/themeConfig/types.ts, src/components/ThemeSwitcher/ThemeSwitcher.tsx, src/components/AuthLayout/AuthLayout.tsx, src/api/axiosInstance.ts, src/contexts/AuthContext.tsx, tailwind.config.js |
 | [AWS Amplify Build & Deploy (non-prod environments)](workflows/amplify-build-and-deploy.md) | How `toga2-commerce` (React + Vite, "commerce2-react") builds and deploys on **AWS Amplify**. | toga2-commerce/amplify.yml, toga2-commerce/.gitattributes, toga2-commerce/package.json, toga2-commerce/.github/workflows/sync-stage-environments.yml |

package/knowledge/2.0/apps/toga2-commerce/features/client-fields.md

@@ -6,7 +6,7 @@ project: TOGa Commerce
 client: shared
 type: feature
 status: active
-updated: 2026-07-10
+updated: 2026-07-14
 owners: ["apeterson", "tcox"]
 files:
   - src/fieldsConfig/index.ts
@@ -15,6 +15,9 @@ files:
   - src/fieldsConfig/clientFields/COMPASSCANADA.json
   - src/fieldsConfig/clientFields/QUAD.json
   - src/pages/Cart/api/CartApi.ts
+  - src/hooks/useAuthenticationFlow.ts
+  - src/contexts/AuthContext.tsx
+  - src/pages/Login/viewModel/useLoginPageViewModel.ts
   - src/hooks/useAssignClientFields.ts
   - src/hooks/useDynamicConditionalFieldOptions.ts
   - src/stores/useFieldsStore.ts
@@ -53,7 +56,11 @@ resolved per tenant, per language, and per role**. There are **two layers**:
   QUAD are `false`.
 - `userApiFields` — the allow-list of user columns fetched at login; importantly it includes the
   tenant's **role flags**: COMPASS/COMPASSCANADA carry `_isAdmin`, `_isSupervisor`, `_isSuperAdmin`;
-  QUAD carries `_isGlobalAdmin`, `_isItShopper`, `_isBuyer`. All include `_personaIds`.
+  QUAD carries `_isGlobalAdmin`, `_isItShopper`, `_isBuyer`. All include `_personaIds`. This key is
+  now the **single source** for every auth-flow user fetch: `AuthContext.tsx`,
+  `useLoginPageViewModel.ts`, and `useAuthenticationFlow.ts` (the SAML post-auth fetch) all resolve
+  it via `getClientLoginFields(host).userApiFields` — there is no longer any hardcoded copy of the
+  user field list anywhere in the app (see the `useAuthenticationFlow` note below).
 - `fetchUsersApiFields` — the allow-list of user columns fetched by the **view-as user search**
   (`fetchUsers()` in `src/pages/Cart/api/CartApi.ts`, driven from `NavIconList.tsx`). Distinct from
   `userApiFields` (which is the login fetch). COMPASS/COMPASSCANADA use the 14-field default list;
@@ -79,6 +86,23 @@ touching Cart code.
 same hardcoded QUAD-vs-default field-list pattern and is a candidate for the identical config
 treatment in a future ticket.
 
+### `userApiFields` and the SAML post-auth fetch (`useAuthenticationFlow`)
+
+`src/hooks/useAuthenticationFlow.ts` no longer hardcodes the user field list for the SAML post-auth
+user fetch. It previously carried an `if (hostNameCode === "QUAD") […] else […]` branch whose two
+lists were **exact element-for-element duplicates** (same order) of the `userApiFields` already in
+`COMPASS.json` / `COMPASSCANADA.json` / `QUAD.json`. It now resolves the list via
+`getClientLoginFields(hostNameCode).userApiFields` — no JSON changes were needed. This is the same
+"config, not `if (client === …)` branches" centralization as the `fetchUsersApiFields`/C6 refactor
+above (sibling ticket TRUE-80015 did the identical treatment for `fetchUsers()` in `CartApi.ts`;
+`useAuthenticationFlow` was TRUE-80017). With this change, `useAuthenticationFlow` was the **last
+remaining hardcoded duplicate** of the user field list — `AuthContext.tsx` and
+`useLoginPageViewModel.ts` already consumed config — so all user-field lists in the app now flow
+through `getClientLoginFields`. Behavior-identical for all tenants, `tsc` clean.
+
+Note: **COMPASSCANADA** previously fell into the generic `else` branch and now resolves to its own
+`COMPASSCANADA.json` (currently identical content to COMPASS — a future divergence point).
+
 ## Layer B — the per-page FIELDS registry
 
 `src/fieldsConfig/index.ts` (~1100 lines) imports every page's per-tenant field constants (which
@@ -219,4 +243,10 @@ Common field attributes: `uuid`, `label`, `valueKey` (path into the data object)
   QUAD = 8-field), replacing the `if (fieldKey === "QUAD")` branch with a config lookup (C6). Noted
   the deliberate QUAD `supervisorUser.*` omission and the `fetchUser()` follow-up candidate. Refactor
   only, no behavior change; `tsc --noEmit` clean. (tcox)
+- 2026-07-14 — Removed the last hardcoded user-field list: `useAuthenticationFlow.ts` (SAML post-auth
+  fetch) now reads `getClientLoginFields(hostNameCode).userApiFields` instead of an
+  `if (hostNameCode === "QUAD") … else …` duplicate of the JSON lists (TRUE-80017; sibling of the
+  TRUE-80015 `fetchUsers` refactor). All user-field lists now flow through config;
+  COMPASSCANADA now resolves its own JSON rather than the generic `else`. Behavior-identical, `tsc`
+  clean. (tcox)
 </content>

package/knowledge/clients/compass-usa/INDEX.md

@@ -6,7 +6,7 @@
 | [Cost Centers — Unit Locations, numeric-only policy](features/cost-centers.md) | 2.0 | A Compass "cost center" — the value a user picks in commerce and that lands on an order — is **not** a `CostCenters` row. | toga2-commerce/src/pages/Cart/api/CartApi.ts, worker1.5/crons/toga2/compass/import_locations.php, _underscore/Model/Compass/SalesOrder.php, api2/Component/Api/V2/V2.php, dbchanges2/Client_Compass/2026-07-06 - RemoveNonNumericCostCenters.sql |
 | [Compass: Item-Fulfillment TableViews (for-sales-order-items & for-sales-orders, tracking via bridge)](features/item-fulfillment-tracking-tableview.md) | 2.0 | Two sibling Compass TableViews in `Client_Compass` display fulfilled items in toga2-supply, both driven by `TableViews` / `TableViewJoins` / `TableViewFields` c | dbchanges2/Client_Compass/2026-06-10 - ItemFulfillmentsForSalesOrderItemsTableView.sql, dbchanges2/Client_Compass/2026-06-11 - ItemFulfillmentsForSalesOrdersTableView.sql, dbchanges2/Client_Compass/2026-06-15a - FixItemFulfillmentTrackingNumberJoins.sql |
 | [Compass MITS PO → SO Item Linking](features/mits-po-to-so-item-linking.md) | 2.0 | MITS sends Compass inbound Purchase Orders (`POST /v2/purchase-orders`) against a Sales Order (`mitsSalesOrder`). | _underscore/Model/Compass/PurchaseOrder.php, worker/crons/toga2/compass/workflow/3a_import_office_depot_purchase_orders.php |
-| [Compass MITS PO Transmission to Vendors](features/mits-po-transmission-to-vendors.md) | 2.0 | The 1.0 worker cron `2_transmit_mits_purchase_orders_to_vendors.php` transmits Compass PurchaseOrders to their vendors (Office Depot, Strategic Systems, Compass | worker/crons/toga2/compass/workflow/2_transmit_mits_purchase_orders_to_vendors.php, library/app/client/compass.php |
+| [Compass MITS PO Transmission to Vendors](features/mits-po-transmission-to-vendors.md) | 2.0 | The 1.0 worker cron `2_transmit_mits_purchase_orders_to_vendors.php` transmits Compass PurchaseOrders to their vendors (Office Depot, Strategic Systems, Compass | worker/crons/toga2/compass/workflow/2_transmit_mits_purchase_orders_to_vendors.php, worker/crons/toga2/compasscanada/workflow/2_transmit_mits_purchase_orders_to_vendors.php, library/app/client/compass.php |
 | [Compass MR/MA Order Auto-Approval & Status Gate](features/mr-ma-order-approval-and-status.md) | 2.0 | Compass **MR** and **MA** sales orders are system-generated from the MITS / Office Depot EDI pipeline (they do not originate as user-entered SA orders) and must | _underscore/Model/Compass/SalesOrder.php, _underscore/Model/Compass/PurchaseOrder.php, worker/crons/toga2/compass/workflow/3a_import_office_depot_purchase_orders.php |
 | [Compass USA](profile.md) | 2.0 | Compass USA is a TOGA client running a multi-tier supply-chain commerce operation. |  |
 | [Compass Cross-Kit Bundle Corruption — Detection & Repair](workflows/cross-kit-bundle-corruption.md) | 2.0 | A frontend regression in `toga2-commerce`'s edit-order bundle submission mis-attributed bundle (kit) line items and **fees/warranties** to the **wrong kit**, pe | src/api/syncSalesOrderItemsFromLocalStorageCartToApi.ts |

package/knowledge/clients/compass-usa/features/mits-po-transmission-to-vendors.md

@@ -5,10 +5,11 @@ project: _Underscore
 client: compass-usa
 type: client-feature
 status: active
-updated: 2026-06-22
-owners: ["rgirish"]
+updated: 2026-07-14
+owners: ["rgirish", "bala"]
 files:
   - worker/crons/toga2/compass/workflow/2_transmit_mits_purchase_orders_to_vendors.php
+  - worker/crons/toga2/compasscanada/workflow/2_transmit_mits_purchase_orders_to_vendors.php
   - library/app/client/compass.php
 related:
   - mits-po-to-so-item-linking.md
@@ -47,6 +48,34 @@ Routing note: Office Depot (vendor 1) `defaultPoSubmissionIntegrationId = 2`, wh
 cXML, unless a `VendorItem` overrides it. There is also a CXML integration (id 1,
 "Office Depot / No") that is NOT the default.
 
+**A single PO can split across channels.** Because grouping is per item
+(`VendorItems.overridePoSubmissionIntegrationId`), the same PO can have some items on the
+EMAIL integration (id 2) and others on the CXML integration (id 1). The emailed PDF therefore
+contains only the **subset** of line items on the EMAIL integration — the CXML items go to
+Office Depot separately with no PDF. Note the PDF's "Order Total" cell prints the whole-PO
+`_total`, **not** a per-integration subtotal, so it can exceed the sum of the items shown.
+
+## PDF rendering (EMAIL branch)
+The EMAIL branch renders the PO with **ezpdf** (`Cezpdf`). The "MAIN ITEM LISTING" draws one
+row per line item; the DESCRIPTION cell is 150pt wide and wraps to multiple lines for long
+descriptions.
+- **Row height must be measured, not assumed.** Each row's true height is taken from the
+  lowest y any cell reached (`ezText` returns the y it finished wrapping at). A row advances
+  by `max($spacingY, ($rowStartY - $rowLowestY) + ($spacingY - $pdf->getFontHeight(11)))` with
+  `$spacingY = 40`: single-line rows stay at 40pt (no regression), multi-line rows grow to fit,
+  and the `($spacingY - getFontHeight)` term gives every row the same trailing gap a
+  single-line row has so tall rows are not cramped.
+- **Pagination is height-aware, not count-based.** Before drawing each row, its wrapped line
+  count is pre-measured and a new page is started before the row would spill past the item box
+  (first page ≈420pt, extra pages ≈625pt). Count-based chunking (8 then 10 per page) overflowed
+  once rows took their true taller height, which made ezpdf's internal `ezText` auto-page-break
+  fire per cell and scatter each cell of the overflowing item onto its own blank page.
+- **Measuring wrapped height without drawing (ezpdf):** call
+  `$pdf->addTextWrap($x, $y, $columnWidth, $size, $text, 'left', 0, 1)` with the last arg
+  (`$test`) = `1`. In test mode `addTextWrap` does not draw (guarded by `if (!$test)`) but wraps
+  identically to `ezText` and returns the remainder, so looping it mirrors `ezText`'s own
+  wrapping exactly — the reliable way to pre-measure a row for pagination decisions.
+
 ## Data model
 - `Client_Compass.PurchaseOrders.dtSubmitted` — set by step 4; the outer query's `IS NULL`
   guard means a PO is only ever picked up once.
@@ -80,6 +109,12 @@ Compass Canada has a parallel `compasscanada/workflow/2_transmit_...` keyed on
   `dtSubmitted` stamped without a log (separate, previously-observed failure mode).
 
 ## Change history
+- 2026-07-14 — Fixed the emailed-PO PDF for both US Compass and Compass Canada: line-item
+  rows now advance by their measured wrapped height (long descriptions no longer overwritten),
+  and pagination is height-aware (a real 21-item PO went from a broken 17-page PDF to a clean
+  3-page one). Recorded the ezpdf `addTextWrap($test=1)` line-height measurement technique and
+  the single-PO EMAIL/CXML channel split (emailed PDF shows only the EMAIL-integration subset;
+  Order Total prints the whole-PO `_total`). (bala)
 - 2026-06-22 — Documented the cron and the unconditional-`dtSubmitted` gotcha: item-less POs
   get marked submitted without transmitting or logging; diagnosed via MR241298 inbound MITS
   payload showing empty item arrays. No code change made (diagnosis only). (rgirish)

package/package.json

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