Workspaces & The Tower

Mallnline organizes its administrative interfaces into Workspaces — role-specific dashboards named after physical spaces within the virtual mall. Each workspace serves a distinct persona and has its own subdomain in the production architecture.

Workspace Architecture

The Tower (`/tower`)

The Tower is the platform-wide admin dashboard. It is restricted to internal Mallnline administrators (is_privileged users only). Non-privileged users are redirected to The Deck.

Access Control

The Tower uses a client-side is_privileged gate:

Authenticated? ───yes──→ is_privileged? ───yes──→ Full Tower Dashboard
                 │                         │
                 no                        no → Redirect to /dashboard
                 │
                 └─→ Redirect to /auth?redirect=/tower

The legacy /admin route redirects to /tower for backward compatibility.

Navigation Entry Points

The Tower link is visible only to privileged users:

Tab Architecture

The Tower uses a primary/secondary tab system with platform-only tabs:

┌──────────────────────────────────────────────────┐
│  Overview │ Users │ Analytics                │ More ▾ │
│                                                  │
│  ┌─ More Dropdown ──────────────┐                │
│  │ Templates │ Search Config │ Deprecation │     │
│  └──────────────────────────────┘                │
└──────────────────────────────────────────────────┘

State type:

let activeTab = $state<
  'overview' | 'users' | 'analytics' |
  'templates' | 'search' | 'deprecation'
>('overview');

The Deck (`deck.mallnline.com`)

The Deck is the Malet Owner standalone workspace. It provides per-malet tools for managing products, analytics, and operations.

Deck Sub-Routes

Deck Query Scoping

Deck sub-routes use scoped queries to ensure owners only see their own data:

// Uses maletId: { in: $maletIds } filter on @FilterableField
export const GET_OWNED_MALET_PRODUCTS = gql`
  query GetOwnedMaletProducts($maletIds: [String!]!, $first: Int!) {
    products(paging: { first: $first }, filter: { maletId: { in: $maletIds } }) {
      edges { node { id name basePrice status totalInventory ... } }
    }
  }
`;

Analytics Sub-Tabs (Tower — Platform-Wide)

The Tower's Analytics tab contains five sub-views showing platform-wide data:

Analytics Sub-Tabs (Deck — Per-Malet)

The Deck's /analytics route shows per-malet analytics (Blog + Media only):

let activeSubTab = $state<'blog' | 'media'>('blog');

Platform-wide analytics (Revenue, Search, Alerts) remain exclusively in The Tower.

Search Analytics Data Sources

The Search Analytics dashboard is unique in that it composes from three separate query patterns rather than a single subgraph analytics resolver:

┌─────────────────────────┐
│    SearchAnalytics       │
├─────────────────────────┤
│                         │
│  1. Zero-query Facet    │──→ SEARCH_ITEMS (q="", limit=0)
│     Search              │    → type, category, malet, section facets
│                         │
│  2. Reconciliation      │──→ GET_RECONCILIATION_STATUS
│     Status              │    → lastRun, added, removed, unchanged, errors
│                         │
│  3. Synonym Coverage    │──→ GET_SEARCH_SYNONYMS
│                         │    → groups per vertical
└─────────────────────────┘

This pattern avoids adding dedicated analytics resolvers to the search subgraph — it reuses existing operational queries and performs client-side aggregation.

Organization Analytics

Separate from The Tower, the Organization Management page (/orgs/[slug]/manage) has its own Analytics tab implemented by OrgAnalyticsPanel.svelte. This tab provides org-scoped metrics:

• KPI Cards: Total Members, Total Activity, Active Contributors, Teams
• Activity Over Time: 30-day bar chart from organizationAuditEvents
• Role Distribution: Donut chart of OWNER/ADMIN/MEMBER ratios
• Event Type Breakdown: Horizontal bars for MEMBER_ADDED, ROLE_CHANGED, etc.
• Top Contributors: Leaderboard with medal emojis
• Teams Table: Sub-group listing from organizationTeams

Like Search Analytics, this uses client-side aggregation from existing queries rather than dedicated analytics resolvers.

Utility Functions

Both analytics components share common formatting utilities:

function formatNumber(n: number): string {
  if (n >= 1_000_000) return (n / 1_000_000).toFixed(1) + 'M';
  if (n >= 1_000) return (n / 1_000).toFixed(1) + 'K';
  return n.toString();
}

function formatDuration(ms: number): string {
  if (ms < 1000) return `${ms}ms`;
  return `${(ms / 1000).toFixed(1)}s`;
}

function timeAgo(dateStr: string): string {
  const diff = Date.now() - new Date(dateStr).getTime();
  const mins = Math.floor(diff / 60000);
  if (mins < 60) return `${mins}m ago`;
  const hrs = Math.floor(mins / 60);
  if (hrs < 24) return `${hrs}h ago`;
  return `${Math.floor(hrs / 24)}d ago`;
}

These are tested in tests/searchAnalytics.test.ts (15 tests), tests/orgAnalytics.test.ts (16 tests), and tests/alertsAnalytics.test.ts (22 tests).

Alerts Analytics Data Sources

The Alerts Analytics dashboard consumes from the alerts subgraph's AlertLog module via GraphQL:

┌─────────────────────────────┐
│      AlertsAnalytics         │
├─────────────────────────────┤
│                             │
│  1. dlqSummary              │──→ Aggregated status counts
│                             │    (PENDING/DELIVERED/FAILED/DEAD + total)
│                             │
│  2. alertLogs(filter)       │──→ Paginated delivery logs
│                             │    → channel, status, eventType, recipient
│                             │    → client-side aggregation for charts
└─────────────────────────────┘

Alerts-specific utilities in src/lib/queries/alerts.ts:

// Aggregate logs by any field (channel, status, eventType)
function aggregateByField<T>(logs: AlertLog[], field: string): { key: T; count: number }[]

// Mask recipients for privacy display
function truncateRecipient(r: string): string  // j***@e***.com or ***4567

// Calculate percentage with 1 decimal
function percentOf(part: number, total: number): string

Display label maps provide human-readable names, colors, and icons:

• CHANNEL_LABELS / CHANNEL_COLORS / CHANNEL_ICONS — EMAIL, SMS, PUSH, IN_APP
• STATUS_LABELS / STATUS_COLORS — PENDING, DELIVERED, FAILED, DEAD
• EVENT_TYPE_LABELS — 12 event types (notify_email, order_status_changed, org_invite_created, etc.)

File Reference

Related

• Standalone Tower Dashboard — Architecture of the standalone extraction and decoupled theme system.
• Tower Subgraph — Rust/Axum subgraph powering The Tower's error tracking data via federated GraphQL
• Tower Health Observability — Dual-layer probing architecture powering the Platform Health widget on the Overview tab
• Alerts & Resilience — Backend alerts subgraph architecture, DLQ, delivery channels
• Search Engine Administration — Backend search operations, reconciliation, and synonym management that power Search Analytics
• Organization Management — Organization manage page and the Analytics tab
• Admin Dashboard & Audit Tools — User-facing support manual for The Tower
• Owner Destinations — The Deck, Register & Pricing — Dedicated Malet Owner routes (/owner/register, /dashboard, /owner/pricing) and tab-by-tab Deck ↔ Tower audit
• Platform Admin Provisioning — Dedicated platform_admins table, invite-chain access control, and 3-tier role system
• Shared Query Package — @ngwenya/queries workspace package that eliminates query duplication across Deck, Tower, and Storefront