@mohasinac/appkit 4.42.2 → 4.42.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/client.d.ts
CHANGED
|
@@ -229,6 +229,15 @@ export { PERMISSION_GROUPS, PERMISSION_DOMAINS, getPermissionsForDomain, formatP
|
|
|
229
229
|
export { Details, Summary } from "./ui/components/Details";
|
|
230
230
|
export { ADMIN_ENDPOINTS } from "./constants/index";
|
|
231
231
|
export { SELLER_ENDPOINTS } from "./constants/index";
|
|
232
|
+
/**
|
|
233
|
+
* The buyer-portal endpoint map. Its admin and seller siblings were already
|
|
234
|
+
* here; this one was reachable only from `index.ts`, so a Client Component
|
|
235
|
+
* needing a /api/user/* URL had to either hardcode the path (blocked by
|
|
236
|
+
* audit-hardcoded-api-routes) or import the bare entry (the firebase-admin
|
|
237
|
+
* client-bundle leak audit-client-server-only-leak blocks). Added for
|
|
238
|
+
* BidDetailPageClient — checklist-page-wiring-detail-pages-detail-page-matches-list-modal.
|
|
239
|
+
*/
|
|
240
|
+
export { ACCOUNT_ENDPOINTS } from "./constants/index";
|
|
232
241
|
export { TourProvider, useTour } from "./_internal/client/features/tour/TourProvider";
|
|
233
242
|
export type { TourContextValue, TourRole } from "./_internal/client/features/tour/TourProvider";
|
|
234
243
|
export { apiClient, ApiClientError } from "./http/index";
|
package/dist/client.js
CHANGED
|
@@ -280,6 +280,15 @@ export { PERMISSION_GROUPS, PERMISSION_DOMAINS, getPermissionsForDomain, formatP
|
|
|
280
280
|
export { Details, Summary } from "./ui/components/Details";
|
|
281
281
|
export { ADMIN_ENDPOINTS } from "./constants/index";
|
|
282
282
|
export { SELLER_ENDPOINTS } from "./constants/index";
|
|
283
|
+
/**
|
|
284
|
+
* The buyer-portal endpoint map. Its admin and seller siblings were already
|
|
285
|
+
* here; this one was reachable only from `index.ts`, so a Client Component
|
|
286
|
+
* needing a /api/user/* URL had to either hardcode the path (blocked by
|
|
287
|
+
* audit-hardcoded-api-routes) or import the bare entry (the firebase-admin
|
|
288
|
+
* client-bundle leak audit-client-server-only-leak blocks). Added for
|
|
289
|
+
* BidDetailPageClient — checklist-page-wiring-detail-pages-detail-page-matches-list-modal.
|
|
290
|
+
*/
|
|
291
|
+
export { ACCOUNT_ENDPOINTS } from "./constants/index";
|
|
283
292
|
// P-16 — Tour system (driver.js-backed onboarding walkthrough).
|
|
284
293
|
export { TourProvider, useTour } from "./_internal/client/features/tour/TourProvider";
|
|
285
294
|
export { apiClient, ApiClientError } from "./http/index";
|
|
@@ -79,7 +79,33 @@ export function AdminSupportTicketsView({ children, ...props }) {
|
|
|
79
79
|
{ value: sortBy("updatedAt", "DESC"), label: "Recently updated" },
|
|
80
80
|
],
|
|
81
81
|
columns: TICKET_COLUMNS,
|
|
82
|
-
|
|
82
|
+
/*
|
|
83
|
+
* 🛑 The item array is `items`. This read `response.tickets`, a key the
|
|
84
|
+
* route does not emit, so EVERY admin saw "No support tickets found".
|
|
85
|
+
*
|
|
86
|
+
* `GET /api/admin/support-tickets` ends in `successResponse(result)` where
|
|
87
|
+
* `result` is `supportRepository.listAll(model)` — a PagedResult, i.e.
|
|
88
|
+
* `{ items, total, page, pageSize, totalPages, hasMore }`. Measured against
|
|
89
|
+
* production: the API returns **total 10** while this list rendered its
|
|
90
|
+
* empty state, so nobody on staff could see a single support ticket.
|
|
91
|
+
*
|
|
92
|
+
* 🛑 I NEARLY MISSED THIS, and the reason is worth recording. The same
|
|
93
|
+
* defect was fixed on the BUYER side (`/user/support`) minutes earlier, and
|
|
94
|
+
* the sweep I ran afterwards searched for the `ok`-vs-`success` envelope
|
|
95
|
+
* flag — not for item-array key misreads — so it reported "no further
|
|
96
|
+
* copies" while this one sat one route away. A sweep narrower than the rule
|
|
97
|
+
* it is checking finds what it was shaped to find (Root Cause #84).
|
|
98
|
+
*
|
|
99
|
+
* A grep of the route then said it emitted `tickets`; the live API said
|
|
100
|
+
* `items`. The grep had matched the word elsewhere in the file. The
|
|
101
|
+
* MEASUREMENT is what settled it, which is the same lesson again.
|
|
102
|
+
*
|
|
103
|
+
* `tickets` is kept in the chain rather than deleted, for the same reason as
|
|
104
|
+
* the buyer-side fix: both spellings demonstrably exist in this codebase,
|
|
105
|
+
* and reading one key too many costs nothing while reading the wrong one
|
|
106
|
+
* cost the entire staff-facing queue.
|
|
107
|
+
*/
|
|
108
|
+
mapRows: (response) => toRecordArray(response.items ?? response.tickets).map((item, index) => ({
|
|
83
109
|
id: toStringValue(item.id, `ticket-${index}`),
|
|
84
110
|
primary: toStringValue(item.subject, "No subject"),
|
|
85
111
|
secondary: [
|