feat(clients): scaffold top-level Clients section with sub-nav around Accounts

backend/migrations/core/097_add_clients_feature_flag.js

@@ -0,0 +1,38 @@
+/**
+ * Migration: Add the `clients` top-level feature flag.
+ *
+ * Introduces a parent flag for the "Clients" sidebar section, which
+ * groups customer accounts today and will host calendar / quotes /
+ * bills / messaging in future PRs. The existing `customerPortal` flag
+ * is unchanged and continues to gate the /customer/* surface plus the
+ * Accounts sub-page; it now lives logically beneath `clients` in the
+ * Features tab.
+ *
+ * Initial value: mirrors the install's current `customerPortal` value
+ * so an admin who had the customer portal enabled keeps seeing the
+ * Clients sidebar entry after upgrade, and an admin who had it off
+ * doesn't suddenly see a new sidebar entry.
+ *
+ * Idempotent: re-runs are no-ops.
+ */
+
+exports.up = async function(knex) {
+  if (!(await knex.schema.hasTable('feature_flags'))) return;
+
+  const existing = await knex('feature_flags').where({ key: 'clients' }).first();
+  if (existing) return;
+
+  const portalRow = await knex('feature_flags').where({ key: 'customerPortal' }).first();
+  let initialValue = false;
+  if (portalRow) {
+    const raw = portalRow.value;
+    initialValue = raw === true || raw === 1 || raw === '1' || raw === 'true';
+  }
+
+  await knex('feature_flags').insert({ key: 'clients', value: initialValue });
+};
+
+exports.down = async function(knex) {
+  if (!(await knex.schema.hasTable('feature_flags'))) return;
+  await knex('feature_flags').where({ key: 'clients' }).del();
+};

backend/server.js

@@ -568,19 +568,23 @@ app.use('/api/admin/photo-export', require('./src/routes/adminPhotoExport'));
 app.use('/api/admin/css-templates', require('./src/routes/adminCssTemplates'));
 app.use('/api/admin/events', require('./src/routes/adminEventRename'));
 app.use('/api/admin/users', require('./src/routes/adminUsers'));
-// Customer portal (#354). The customerPortal feature flag is enforced
-// on the frontend via <RequireFeature flag="customerPortal" /> route
-// guards (App.tsx) and AdminSidebar visibility — when the flag is off,
-// users never reach these endpoints. Defence in depth is provided by
-// customerAccountsService.isCustomerPortalEnabled() in the few backend
-// paths that matter (e.g. adminEvents customer_account_ids handling).
-// Admin routes are protected by adminAuth; customer routes by
-// customerAuth — so no additional route-level gate is needed.
-app.use('/api/admin/customers', require('./src/routes/adminCustomers'));
+// Customer portal (#354). When the `customerPortal` feature flag is
+// OFF, both the admin-facing /api/admin/customers/* surface AND the
+// customer-facing /api/customer/* surface return 410 Gone — turning
+// the toggle off in Settings → Features cleanly kills the feature
+// everywhere, not just in the UI. The frontend RequireFeature guard
+// + AdminSidebar visibility still apply for navigation, but a stale
+// tab or third-party API client can't bypass the gate.
+const {
+  requireCustomerPortalEnabled,
+  requireCustomerPortalEnabledAdmin,
+} = require('./src/middleware/requireCustomerPortal');
+
+app.use('/api/admin/customers', requireCustomerPortalEnabledAdmin, require('./src/routes/adminCustomers'));
 // Customer-side surface (#354). Strictly separate from /api/admin/* —
 // distinct token type, distinct cookie, distinct middleware.
-app.use('/api/customer/auth', require('./src/routes/customerAuth'));
-app.use('/api/customer', require('./src/routes/customer'));
+app.use('/api/customer/auth', requireCustomerPortalEnabled, require('./src/routes/customerAuth'));
+app.use('/api/customer', requireCustomerPortalEnabled, require('./src/routes/customer'));
 app.use('/api/admin/event-types', require('./src/routes/adminEventTypes'));
 app.use('/api/admin/api-tokens', require('./src/routes/adminApiTokens'));
 app.use('/api/admin/webhooks', require('./src/routes/adminWebhooks'));

backend/src/middleware/requireCustomerPortal.js

@@ -0,0 +1,62 @@
+/**
+ * Customer portal feature-flag gate.
+ *
+ * Blocks every /api/customer/* and /api/admin/customers/* endpoint
+ * when the `customerPortal` flag is off. Returns 410 Gone so the
+ * frontend can distinguish "feature has been disabled" from "you
+ * don't have access" (which would be 403) — useful for the customer
+ * dashboard's auto-redirect on a soft-kill scenario.
+ *
+ * Reads the flag via customerAccountsService.isCustomerPortalEnabled
+ * (which itself reads from the maintainer's feature_flags table),
+ * so a single source of truth.
+ */
+
+const customerAccountsService = require('../services/customerAccountsService');
+const logger = require('../utils/logger');
+
+async function isEnabled() {
+  try {
+    return await customerAccountsService.isCustomerPortalEnabled();
+  } catch (err) {
+    // Defensive: if the lookup throws (DB unavailable, table missing
+    // mid-migration), fail closed so an enabled-by-default fallback
+    // can't accidentally expose customer surfaces during boot.
+    logger.warn('requireCustomerPortal: feature flag lookup failed, treating as off', {
+      error: err?.message,
+    });
+    return false;
+  }
+}
+
+/**
+ * Customer-facing endpoints. Returns 410 with a code the frontend
+ * can interpret to clear stale session storage + redirect to
+ * /admin/login.
+ */
+async function requireCustomerPortalEnabled(req, res, next) {
+  if (await isEnabled()) return next();
+  return res.status(410).json({
+    error: 'Customer portal is disabled',
+    code: 'CUSTOMER_PORTAL_DISABLED',
+  });
+}
+
+/**
+ * Admin-facing /api/admin/customers/* endpoints. Same gate, same
+ * status code — keeps the contract consistent across both halves of
+ * the customer-portal surface. The sidebar UI already hides the
+ * entry, but a stale tab or direct API call must also be blocked.
+ */
+async function requireCustomerPortalEnabledAdmin(req, res, next) {
+  if (await isEnabled()) return next();
+  return res.status(410).json({
+    error: 'Customer portal is disabled',
+    code: 'CUSTOMER_PORTAL_DISABLED',
+  });
+}
+
+module.exports = {
+  requireCustomerPortalEnabled,
+  requireCustomerPortalEnabledAdmin,
+};

backend/src/routes/adminFeatureFlags.js

@@ -32,8 +32,14 @@ const KNOWN_FLAGS = [
   'messaging',
   'analytics',
   'userManagement',
-  // Foundation flag for the customer-side surface (#354). See migration
-  // 094 for the seeding rule.
+  // Top-level "Clients" section (#354 follow-up). Parent flag that
+  // gates the /admin/clients/* sidebar entry. customerPortal,
+  // calendar, quotes, bills and messaging are conceptually its
+  // children — when `clients` is off none of them surface in the
+  // admin UI even if their individual flags are on.
+  'clients',
+  // Customer-side portal surface (#354). Gates /customer/* routes
+  // and the Accounts sub-page under Clients. See migration 095.
   'customerPortal',
 ];
 
@@ -49,6 +55,7 @@ const DEFAULT_FLAGS = {
   messaging: false,
   analytics: true,
   userManagement: true,
+  clients: false,
 };
 
 async function readAllFlags() {
@@ -69,13 +76,27 @@ function applyDependencyRules(flags) {
   // Sub-features can't outlive their parents.
   if (out.quotes === false) out.bills = false;
   if (out.calendar === false) out.calendarBooking = false;
+  // Clients parent flag is DERIVED from its children. Admins don't
+  // toggle it directly in the Features tab — they enable a specific
+  // sub-feature (Accounts today; Calendar/Quotes/Bills/Messaging
+  // later) and the Clients sidebar section lights up automatically.
+  // Computing the value here (rather than only on writes) means GET
+  // /admin/feature-flags also returns a consistent state if the DB
+  // ever drifts (e.g. partial migration run).
+  out.clients = Boolean(
+    out.customerPortal
+    // future siblings (out.calendar || out.quotes || out.bills || out.messaging) go here
+  );
   return out;
 }
 
 router.get('/', adminAuth, requirePermission('settings.view'), async (req, res) => {
   try {
     const flags = await readAllFlags();
-    res.json(flags);
+    // Always run the rules so derived flags (e.g. `clients`) and
+    // hard invariants (galleries always on) are consistent even if
+    // the DB row is stale or missing.
+    res.json(applyDependencyRules(flags));
   } catch (error) {
     logger.error('Failed to read feature flags', { error: error.message });
     res.status(500).json({ error: 'Failed to read feature flags' });