The previous commit taught bulk editing and delete-with-restore about the BC catalog. Neither actually worked, and one of them was destructive. `catalog_items_bc` has six columns: id, item_ids, page_id, catalog_name, order_number, extradata. There is no price, points, currency, offer_id, limit or membership column on it. The bulk path read and wrote columns that do not exist, and the UPDATE was aimed at catalog_items while the SELECT came from catalog_items_bc — so a BC category move wrote into the normal catalog. Two tests now pin that pairing: reads and writes have to stay in the same table. Underneath it the BC table was never being read at all. The inline editor fetched `/api/admin/catalog/items?pageId=N` without the catalog, so opening a BC category showed the normal catalog's offers, and the route selected BC rows directly instead of going through the loader, skipping the furni enrichment the table needs to render anything but a bare caption. Both catalogs now take the same path, and the catalog is in the fetch callback's dependencies — without that, a switch keeps reading the previous catalog's rows through a stale closure. Because a BC offer has no price, the editor no longer offers one. The server refuses price, points and currency changes with a readable message instead of letting them reach the database as an unknown-column error, and a BC bulk edit is what it can actually be: a category move. BC deletions also went through a bare DELETE, which made them the one catalog mutation with no way back. They now keep their rows and hand back a restoreId like the normal ones. The catalog is recorded in the audit target rather than in the payload, so a restore can never put a BC row into the normal offers table.
26 lines
887 B
TypeScript
26 lines
887 B
TypeScript
import { apiError, apiOk } from "@/lib/api";
|
|
import { withAdmin } from "@/lib/api-handler";
|
|
import { PERMS } from "@/lib/permissions";
|
|
import { loadCatalogItemsData } from "@/lib/services/catalog-items-loader";
|
|
|
|
export const GET = withAdmin(
|
|
{ permission: PERMS.CATALOG_VIEW },
|
|
async (request) => {
|
|
const pageId = Number(request.nextUrl.searchParams.get("pageId"));
|
|
if (!Number.isFinite(pageId) || pageId <= 0) {
|
|
return apiError("Invalid pageId");
|
|
}
|
|
const catalog =
|
|
request.nextUrl.searchParams.get("catalog") === "bc" ? "bc" : "normal";
|
|
// Both catalogs go through the loader. The BC branch used to select the
|
|
// rows directly, which returned them without the furni enrichment the
|
|
// table needs to render anything but a bare caption.
|
|
return apiOk(
|
|
(await loadCatalogItemsData(pageId, catalog)) as unknown as Record<
|
|
string,
|
|
unknown
|
|
>,
|
|
);
|
|
},
|
|
);
|