@mohasinac/appkit 4.35.1 → 4.35.3

package/dist/_internal/client/features/layout/DashboardLayoutClient.js

@@ -122,13 +122,28 @@ function useResponsiveDrawer(storageKey) {
 }
 /** Filter nav groups by navConfig (enabled toggle) + requiredPermission. */
 function filterGroups(groups, navConfig, permissions) {
-    // null permissions = admin (show everything); undefined = no filtering (backwards compat)
-    if (permissions === null && !navConfig)
+    /*
+     * `permissions === null` MEANS ADMIN, and that must hold whether or not a
+     * navConfig exists.
+     *
+     * The early return below encoded the convention correctly and then applied it
+     * only when `!navConfig`. The moment site settings carried ANY nav config,
+     * an admin fell through to `filterNavItems(..., undefined)` — and
+     * `undefined?.includes(x)` is falsy, so every item carrying a
+     * `requiredPermission` was dropped. The Admin Panel sidebar rendered empty
+     * while every admin page stayed reachable by URL.
+     *
+     * Passing `isAdmin` keeps the admin's navConfig toggles working (disabling an
+     * entry is a configuration decision, not a permission) while granting the
+     * permissions an admin implicitly holds.
+     */
+    const isAdmin = permissions === null;
+    if (isAdmin && !navConfig)
         return groups;
     return groups
         .map((group) => ({
         ...group,
-        items: filterNavItems(group.items, navConfig, permissions ?? undefined),
+        items: filterNavItems(group.items, navConfig, permissions ?? undefined, isAdmin),
     }))
         .filter((group) => group.items.length > 0);
 }

package/dist/_internal/client/features/layout/filterNavItems.d.ts

@@ -8,8 +8,29 @@ type FilterableItem = {
  * 2. requiredPermission — item hidden when user lacks the permission
  *
  * Items without an `id` always pass through (legacy / unmanaged items).
+ *
+ * 🛑 A FULL ADMIN HOLDS EVERY PERMISSION IMPLICITLY — `permissions[]` REFINES
+ * EMPLOYEES, IT DOES NOT DEFINE ADMINS.
+ *
+ * That is how the rest of the system already works: every admin route guard is
+ * `roles: ROLES_ADMIN_ONLY`, and employees are the ones who carry explicit
+ * grants (the seeded employees hold 5 and 24 permissions respectively, while
+ * `user-admin-letitrip` holds NONE — matching its seed, so this is by design
+ * rather than drift). There is no role→permission derivation anywhere in the
+ * codebase for the nav to lean on.
+ *
+ * Without `isAdmin` here, an admin matched no `requiredPermission` and EVERY
+ * admin nav item was filtered out: the Admin Panel sidebar rendered completely
+ * empty, and searching it returned "No matches". Every admin page stayed
+ * reachable by typing its URL, which is exactly what made it look cosmetic.
+ *
+ * This surfaced only recently because the check had never run: `filterNavItems`
+ * opens with `if (!item.id) return true;` and no item carried an `id` until
+ * ids were derived (see navigation.tsx). Turning a dormant check on without the
+ * data to satisfy it is the same shape as seeding a ratchet from the wrong
+ * measurement — Root Cause #84.
  */
 export declare function filterNavItems<T extends FilterableItem>(items: T[], navConfig: Record<string, {
     enabled: boolean;
-}> | undefined, userPermissions: string[] | undefined): T[];
+}> | undefined, userPermissions: string[] | undefined, isAdmin?: boolean): T[];
 export {};

package/dist/_internal/client/features/layout/filterNavItems.js

@@ -4,13 +4,38 @@
  * 2. requiredPermission — item hidden when user lacks the permission
  *
  * Items without an `id` always pass through (legacy / unmanaged items).
+ *
+ * 🛑 A FULL ADMIN HOLDS EVERY PERMISSION IMPLICITLY — `permissions[]` REFINES
+ * EMPLOYEES, IT DOES NOT DEFINE ADMINS.
+ *
+ * That is how the rest of the system already works: every admin route guard is
+ * `roles: ROLES_ADMIN_ONLY`, and employees are the ones who carry explicit
+ * grants (the seeded employees hold 5 and 24 permissions respectively, while
+ * `user-admin-letitrip` holds NONE — matching its seed, so this is by design
+ * rather than drift). There is no role→permission derivation anywhere in the
+ * codebase for the nav to lean on.
+ *
+ * Without `isAdmin` here, an admin matched no `requiredPermission` and EVERY
+ * admin nav item was filtered out: the Admin Panel sidebar rendered completely
+ * empty, and searching it returned "No matches". Every admin page stayed
+ * reachable by typing its URL, which is exactly what made it look cosmetic.
+ *
+ * This surfaced only recently because the check had never run: `filterNavItems`
+ * opens with `if (!item.id) return true;` and no item carried an `id` until
+ * ids were derived (see navigation.tsx). Turning a dormant check on without the
+ * data to satisfy it is the same shape as seeding a ratchet from the wrong
+ * measurement — Root Cause #84.
  */
-export function filterNavItems(items, navConfig, userPermissions) {
+export function filterNavItems(items, navConfig, userPermissions, isAdmin = false) {
     return items.filter((item) => {
         if (!item.id)
             return true;
+        // The admin toggle still applies to admins — disabling a nav entry is a
+        // deliberate configuration choice, not a permission the admin outranks.
         if (!(navConfig?.[item.id]?.enabled ?? true))
             return false;
+        if (isAdmin)
+            return true;
         if (item.requiredPermission && !userPermissions?.includes(item.requiredPermission))
             return false;
         return true;

package/dist/_internal/server/features/checkout/actions.js

@@ -12,7 +12,7 @@ import { roundRupees } from "../../../../utils/number.formatter";
 import { ApiError, ValidationError, NotFoundError, ERROR_MESSAGES } from "../../../../errors";
 import { ORDER_FIELDS } from "../../../../constants/field-names";
 import { serverLogger } from "../../../../monitoring";
-import { unitOfWork, siteSettingsRepository, userRepository, storeRepository, couponsRepository, claimedCouponsRepository, addressesRepository, productRepository, } from "../../../../repositories";
+import { unitOfWork, adminNotificationsRepository, siteSettingsRepository, userRepository, storeRepository, couponsRepository, claimedCouponsRepository, addressesRepository, productRepository, } from "../../../../repositories";
 import { computePreOrderDepositAmount, lineTotalFor, sumGroupGst, unitPriceFor, } from "../../../shared/checkout/order-math";
 import { failedCheckoutRepository } from "../../../../features/checkout/repository/failed-checkout.repository";
 import { sendOrderConfirmationEmail } from "../../../../features/contact/server";
@@ -1099,28 +1099,34 @@ async function refundDroppedItemsForRazorpayCheckout(input) {
             void normalizeError(updErr);
             serverLogger.error("verifyAndPlaceRazorpayOrderAction: failed to flag refundPending after auto-refund failure", { orderId: primaryOrderId, err: updErr instanceof Error ? updErr.message : String(updErr) });
         });
-        // Best-effort admin fan-out — mirrors onScamReportCreate's employee
-        // notification pattern. Never allowed to throw past this point.
-        try {
-            const admins = await userRepository.list({ filters: "role==admin", page: 1, pageSize: 100 });
-            await Promise.all(admins.items
-                .filter((a) => !!a.id)
-                .map((admin) => sendNotification({
-                userId: admin.id,
-                type: "system",
-                priority: "high",
-                title: "Automatic refund failed",
-                message: `Automatic refund failed for order ${primaryOrderId} (${unavailablePaid.length} unavailable item(s)) — manual refund required.`,
-                relatedId: primaryOrderId,
-                relatedType: "order",
-                userEmail: admin.email ?? undefined,
-                userPhone: admin.phoneNumber ?? undefined,
-            }).catch((notifErr) => serverLogger.error("Failed to notify admin of failed auto-refund (non-fatal)", notifErr))));
-        }
-        catch (notifyErr) {
+        /*
+         * One admin-inbox row, not one notification per admin.
+         *
+         * 🛑 The comment that used to sit here said this "mirrors
+         * onScamReportCreate's employee notification pattern" — and it did, which
+         * is exactly the problem: that pattern was a 100-way concurrent fan-out of
+         * an email-eligible type, and it has been removed. A failed auto-refund is
+         * ONE event needing ONE person to act, not N personal messages.
+         *
+         * It also no longer queries the admin list at all, so the failure mode
+         * where "we couldn't look up the admins" silently swallowed the alert is
+         * gone with it.
+         */
+        await adminNotificationsRepository
+            .create({
+            category: "payouts",
+            title: "Automatic refund failed",
+            body: `Automatic refund failed for order ${primaryOrderId} (${unavailablePaid.length} unavailable item(s)) — manual refund required.`,
+            severity: "error",
+            isRead: false,
+            entityType: "order",
+            entityId: primaryOrderId,
+            audienceUserIds: [],
+        })
+            .catch((notifyErr) => {
             void normalizeError(notifyErr);
-            serverLogger.error("verifyAndPlaceRazorpayOrderAction: failed to query admins for failed auto-refund notification", { orderId: primaryOrderId });
-        }
+            serverLogger.error("verifyAndPlaceRazorpayOrderAction: failed to write admin notification for failed auto-refund", { orderId: primaryOrderId });
+        });
     }
 }
 /**

package/dist/_internal/server/features/media/contextGuards.d.ts

@@ -49,5 +49,5 @@ interface GuardInput {
  * derive the SEO filename. Mirrors the inline logic that used to live
  * in /api/media/upload.
  */
-export declare function applyMediaContextGuards({ detectedMime, context: ctx, }: GuardInput): GuardResult;
+export declare function applyMediaContextGuards(input: GuardInput): GuardResult;
 export {};

package/dist/_internal/server/features/media/contextGuards.js

@@ -11,6 +11,7 @@
  */
 import { classifyMime, MIME_TO_EXT, PRODUCT_IMAGE_INDEX_MAX, PRODUCT_MAX_VIDEOS, } from "../../../shared/media/limits";
 import { generateMediaFilename, validateMediaFilename, } from "../../../../utils/id-generators";
+import { normalizeError } from "../../../../errors/normalize";
 /**
  * W1-51 — validate the generated filename before returning ok:true so a
  * malformed name can never enter signed-URL storage. Generators producing
@@ -89,7 +90,39 @@ function indexGuard(receivedIndex, max, errorMessage) {
  * derive the SEO filename. Mirrors the inline logic that used to live
  * in /api/media/upload.
  */
-export function applyMediaContextGuards({ detectedMime, context: ctx, }) {
+/*
+ * 🛑 A MISSING CONTEXT FIELD IS A 400, NEVER A 500.
+ *
+ * The filename generators slugify their inputs, and `slugify(undefined)` throws
+ * `Cannot read properties of undefined (reading 'toLowerCase')` from deep inside
+ * `id-generators`. That escaped `applyMediaContextGuards` as an unhandled throw,
+ * so `/api/media/sign` answered 500 INTERNAL — twice in production — for what is
+ * simply a caller that forgot a field. The guards below validate `index` but
+ * have never validated the string fields, and enumerating every generator's
+ * requirements here would drift from the generators themselves (Root Cause #61).
+ *
+ * So the boundary catches instead: whatever the generator needs, failing to
+ * supply it now returns an actionable 400 naming the context type, and the real
+ * message is logged rather than shown. The caller-side fix still matters — this
+ * only guarantees the failure mode is honest.
+ */
+export function applyMediaContextGuards(input) {
+    try {
+        return applyMediaContextGuardsInner(input);
+    }
+    catch (err) {
+        const normalized = normalizeError(err);
+        const message = normalized.message;
+        return {
+            ok: false,
+            status: 400,
+            error: `The upload context for "${input.context?.type ?? "unknown"}" is missing a required field. ` +
+                `Check every field its filename pattern needs.`,
+            details: { context: input.context?.type, thrown: message },
+        };
+    }
+}
+function applyMediaContextGuardsInner({ detectedMime, context: ctx, }) {
     const kind = classifyMime(detectedMime);
     if (!kind) {
         return {

package/dist/_internal/server/features/orders/actions.js

@@ -1,6 +1,6 @@
 "use server";
 import { wrapAction } from "@mohasinac/appkit/server";
-import { orderRepository, storeRepository, userRepository } from "../../../../repositories";
+import { adminNotificationsRepository, orderRepository, storeRepository } from "../../../../repositories";
 import { requireRoleUser } from "../../../../providers/auth-firebase/helpers";
 import { createOrderSchema, updateOrderStatusSchema, cancelOrderSchema, returnRequestSchema, } from "../../../shared/features/orders/schema";
 import { isFinalSaleExempt } from "../../../shared/features/orders/return-reasons";
@@ -115,51 +115,44 @@ function normalizeUpi(vpa) {
 }
 const REASON_REQUIRED_MSG = "A reason is required";
 /**
- * Fast-review WhatsApp push — fans out to every configured admin number so
- * a payment proof can be acted on within the 2-hour auto-approve window
- * without hunting through the orders list. Fire-and-forget, non-fatal on
- * failure (mirrors the existing `onOrderCreate.ts` purchase-announcement
- * pattern) — skips silently if the WhatsApp Cloud API isn't configured.
+ * Fast-review signal — a payment proof needs acting on inside the 2-hour
+ * auto-approve window, and the admin should not have to hunt the orders list
+ * to find it.
+ *
+ * 🛑 This used to `Promise.allSettled` a WhatsApp message to EVERY number in
+ * `whatsappAdminNotifyNumbers`, on every proof upload. Three problems, in
+ * increasing order of importance:
+ *
+ *   1. it was an unbounded fan-out on a metered channel;
+ *   2. WhatsApp free-form messages are rejected by Meta outside the 24-hour
+ *      customer-service window, so the alert most likely to matter — the one
+ *      arriving after a quiet period — is precisely the one that would fail;
+ *   3. it left no record. A missed push was simply gone, whereas the queue at
+ *      `/admin/orders` is the thing an admin actually works from.
+ *
+ * One `adminNotifications` row instead: durable, deduplicated by nature, read
+ * by the admin inbox, and counted in the daily digest. Still fire-and-forget
+ * and still non-fatal — the buyer's upload already succeeded, and a failure to
+ * announce it must never surface as an upload error.
  */
 function notifyAdminsOfPaymentProof(order) {
     void (async () => {
         try {
-            const [{ resolveKeys }, { sendWhatsAppBusinessMessage, buildPaymentProofReviewMessage }] = await Promise.all([
-                import("../../../../core/integration-keys"),
-                import("../../../../features/whatsapp-bot/server"),
-            ]);
-            const keys = await resolveKeys();
-            if (!keys.whatsappPhoneNumberId || !keys.whatsappCloudApiToken)
-                return;
-            const adminNumbers = keys.whatsappAdminNotifyNumbers
-                .split(",")
-                .map((n) => n.trim().replace(/\D/g, ""))
-                .filter(Boolean);
-            if (adminNumbers.length === 0)
-                return;
-            // No hardcoded domain fallback here (audit-ssr-in-appkit) — every
-            // consumer sets NEXT_PUBLIC_SITE_URL; skip the review link rather than
-            // guessing a brand-specific domain from inside appkit/_internal/.
-            const baseUrl = process.env.NEXT_PUBLIC_SITE_URL ?? "";
-            const message = buildPaymentProofReviewMessage({
-                orderId: order.id,
-                buyerName: order.userName,
-                productTitle: order.productTitle,
-                totalAmount: order.totalPrice,
-                reviewUrl: `${baseUrl}/admin/orders`,
+            const { adminNotificationsRepository } = await import("../../../../repositories");
+            await adminNotificationsRepository.create({
+                category: "payouts",
+                title: "Payment proof awaiting review",
+                body: `${order.userName} uploaded proof for "${order.productTitle}" (₹${order.totalPrice.toLocaleString("en-IN")}). Review before the 2-hour auto-approve window closes.`,
+                severity: "warning",
+                isRead: false,
+                entityType: "order",
+                entityId: order.id,
+                audienceUserIds: [],
             });
-            await Promise.allSettled(adminNumbers.map((toPhone) => sendWhatsAppBusinessMessage({
-                toPhone,
-                message,
-                phoneNumberId: keys.whatsappPhoneNumberId,
-                accessToken: keys.whatsappCloudApiToken,
-            })));
         }
         catch (err) {
             void normalizeError(err);
-            // Non-fatal — the order itself already saved successfully; a WhatsApp
-            // Cloud API hiccup here must never surface as a proof-upload failure.
-            serverLogger.warn("Payment-proof admin WhatsApp push failed (non-fatal)", {
+            serverLogger.warn("Payment-proof admin notification failed (non-fatal)", {
                 orderId: order.id,
                 error: err instanceof Error ? err.message : String(err),
             });
@@ -384,17 +377,33 @@ export async function raiseOrderDisputeAction(orderId, reason) {
             disputeReason: reason,
             disputeStatus: "open",
         });
-        // Notify every admin for manual investigation — a dispute on an
-        // auto-approved order means nobody has looked at it yet.
-        const admins = await userRepository.findByRole("admin");
-        await Promise.allSettled(admins.map((admin) => sendNotification({
-            userId: admin.uid,
-            type: "payment_review",
-            priority: "high",
+        /*
+         * One admin-inbox row, not one notification per admin.
+         *
+         * 🛑 This was `Promise.allSettled` over `userRepository.findByRole("admin")`
+         * sending `payment_review` — an email-ELIGIBLE type — so a single disputed
+         * order cost one email per admin, concurrently. Same defect as the
+         * scam-report employee blast (removed in the same change), and the comment
+         * on that one said it was copying this pattern.
+         *
+         * `adminNotifications` is durable, appears in the admin inbox, is counted
+         * in the daily digest, and costs exactly one write regardless of how many
+         * admins exist.
+         */
+        await adminNotificationsRepository
+            .create({
+            category: "fraud",
             title: "Dispute raised on auto-approved order",
-            message: `A dispute was raised on order "${order.productTitle}" (auto-approved payment). Reason: ${reason}.`,
-            relatedId: orderId,
-            relatedType: "order",
-        })));
+            body: `A dispute was raised on order "${order.productTitle}" (auto-approved payment). Reason: ${reason}.`,
+            severity: "error",
+            isRead: false,
+            entityType: "order",
+            entityId: orderId,
+            audienceUserIds: [],
+        })
+            .catch((err) => {
+            void normalizeError(err);
+            serverLogger.error("Failed to write dispute admin notification (non-fatal)", { orderId });
+        });
     });
 }

package/dist/_internal/server/features/site-settings/adapters.d.ts

@@ -39,7 +39,7 @@ import type { PublicSiteSettings } from "../../../shared/features/site-settings/
  */
 export declare const PUBLIC_SITE_SETTINGS_FIELDS: readonly ["contact", "payment", "listings", "notificationChannels", "announcementBar", "navConfig", "actionConfig", "background", "watermark"];
 /** Everything else, with the reason it stays server-side. */
-export declare const PRIVATE_SITE_SETTINGS_FIELDS: readonly ["id", "createdAt", "updatedAt", "credentials", "emailSettings", "legalPages", "commissions", "emi", "gst", "laborRate", "adSettings", "integrations", "platformLimits", "auctionConfig", "disabledRoutes", "siteName", "tagline", "motto", "logo", "favicon", "seo", "socialLinks", "features", "shipping", "returns", "faq", "aboutContent", "navbarConfig", "footerConfig", "theme", "featuredResults"];
+export declare const PRIVATE_SITE_SETTINGS_FIELDS: readonly ["id", "createdAt", "updatedAt", "credentials", "emailSettings", "legalPages", "commissions", "emi", "gst", "laborRate", "adSettings", "integrations", "platformLimits", "auctionConfig", "disabledRoutes", "siteName", "tagline", "motto", "logo", "favicon", "seo", "socialLinks", "features", "shipping", "returns", "faq", "aboutContent", "navbarConfig", "footerConfig", "theme", "featuredResults", "messaging"];
 export interface ToPublicSiteSettingsOptions {
     /**
      * The resolved marker → wordmark → text watermark chain. Injected because

package/dist/_internal/server/features/site-settings/adapters.js

@@ -47,6 +47,14 @@ export const PRIVATE_SITE_SETTINGS_FIELDS = [
     "footerConfig", // rendered server-side
     "theme", // delivered as an SSR prop to ThemeProvider by app/[locale]/layout.tsx
     "featuredResults", // rendered server-side by search
+    // Kill switch + daily send ceiling. Read ONLY by guardSend, server-side. Two
+    // reasons it stays private beyond "no client reader": the ceiling and the
+    // headroom left in it are operational detail, and publishing "user email is
+    // currently off" tells an attacker that password-reset traffic is going
+    // unwatched. The one client that arguably wants it — the admin ticket-reply
+    // checkbox, which disables itself when email is off — is behind the admin
+    // API, which returns the full document.
+    "messaging",
 ];
 export function toPublicSiteSettings(doc, opts) {
     return {

package/dist/_internal/server/jobs/core/auctionSettlement.js

@@ -112,6 +112,10 @@ async function settleAuction(ctx, product) {
                 relatedType: "product",
             });
         }
+        // audit-unguarded-send-ok: `bid_lost` is email-INELIGIBLE — these return at
+        // the eligibility gate having written only the bell row, so they never
+        // reach the budget counter. Same reasoning as the settled-auction fan-out
+        // below.
         await Promise.allSettled(activeBids.slice(0, 50).map(({ data: bid }) => sendNotification({
             userId: bid.userId,
             type: "bid_lost",
@@ -181,6 +185,15 @@ async function settleAuction(ctx, product) {
         actionUrl: AUCTION_CHECKOUT_URL,
         actionLabel: AUCTION_MESSAGES.WON_ACTION_LABEL,
     });
+    // audit-unguarded-send-ok: `bid_lost` is email-INELIGIBLE, so every one of
+    // these returns at the eligibility gate in sendNotification having written
+    // only the in-app bell row — it never reaches guardSend or the daily budget
+    // counter, so there is nothing here to contend on. This was THE fan-out that
+    // motivated the whole change (50 concurrent emails per settled auction, with
+    // every expired auction settling at once); it is now 50 concurrent Firestore
+    // writes to 50 DIFFERENT notification documents, which is what this loop
+    // always was underneath. If `bid_lost` is ever made eligible, this must
+    // become sequential and the counter must be sharded first.
     await Promise.allSettled(loserEntries.slice(0, 50).map(({ data: bid }) => sendNotification({
         userId: bid.userId,
         type: "bid_lost",

package/dist/_internal/server/jobs/core/dailyStatusDigest.d.ts

@@ -13,12 +13,37 @@
  * sync ceiling — it has the Function's much larger budget.
  */
 import type { JobContext } from "../runtime/types";
+/** One inbound contact message, rendered with a mailto: reply link. */
+export interface DigestContactMessage {
+    id: string;
+    name: string;
+    email: string;
+    subject: string;
+    /** First ~200 chars. The full text is in /admin/contact. */
+    excerpt: string;
+}
 export interface DailyStatusDigestSummary {
     orderCount: number;
     revenue: number;
     statusBreakdown: Record<string, number>;
     stuckPendingCount: number;
     activeListingCount: number;
+    /** New in the last 24h, listed in full up to CONTACT_PREVIEW_LIMIT. */
+    contactMessages: DigestContactMessage[];
+    contactTotal: number;
+    /** New tickets in 24h, plus the standing backlog by status. */
+    newTicketCount: number;
+    ticketsOpen: number;
+    ticketsInProgress: number;
+    ticketsWaitingOnUser: number;
+    newScamReportCount: number;
+    /** Orders sitting in the manual-payment pending state (proof upload / review). */
+    manualPaymentPendingCount: number;
+    /** Count only — subscriber emails are PII-encrypted with an HMAC blind index. */
+    newSubscriberCount: number;
+    /** Privileged admin actions recorded in 24h — replaces the per-save settings email. */
+    adminActionCount: number;
+    unreadAdminNotificationCount: number;
 }
 /** Gathers the last-24h numbers. Exported so the admin manual-trigger route can reuse it. */
 export declare function collectDailyStatusSummary(): Promise<DailyStatusDigestSummary>;