Platform Admin Provisioning

The Tower is Mallnline's internal platform administration dashboard. Access is controlled by a dedicated platform_admins table in the auth Postgres database — completely decoupled from Organization membership. This means a Malet Owner who creates an Organization does not automatically become a platform admin.

Architecture

The Problem (Pre-Provisioning)

Previously, is_privileged_user() in the auth service queried org_members for OWNER or ADMIN roles. This meant:

• Any Malet Owner who created an Organization automatically got Tower access
• No way to distinguish between "Org Admin" and "Platform Admin"
• No audit trail for who granted platform access

The Solution

A dedicated platform_admins table with:

• Invite-chain provisioning — all admins trace back to a seeded SUPER_ADMIN
• 3-tier role system — SUPER_ADMIN, ADMIN, VIEWER
• Soft-delete revocation — revoked_at timestamp for access removal
• Domain restriction — only @mallnline.com emails

┌─────────────┐     invite     ┌─────────────┐     invite     ┌─────────────┐
│ SUPER_ADMIN │───────────────▶│    ADMIN     │       ✗        │   VIEWER    │
│  (seeded)   │               │ (can manage) │               │ (read-only) │
└─────────────┘               └─────────────┘               └─────────────┘
       │                                                           ▲
       └───────────────────────────────────────────────────────────┘
                              invite

Only SUPER_ADMIN users can send invites. ADMIN and VIEWER roles cannot escalate.

Database Schema

`platform_admins` Table

`platform_admin_invites` Table

REST API

All endpoints are on the auth service and require authentication via session cookie.

`POST /admin/invite`

Create a platform admin invite. SUPER_ADMIN only.

// Request
{
  "email": "alice@mallnline.com",
  "role": "ADMIN"  // or "VIEWER", defaults to "ADMIN"
}

// Response (200)
{
  "message": "Invite created successfully",
  "email": "alice@mallnline.com",
  "role": "ADMIN",
  "token": "a1b2c3...96chars",
  "expires_at": "2026-04-22T18:00:00Z"
}

Error responses:

`POST /admin/invite/accept`

Accept an invite. Any authenticated user (must match invite email).

// Request
{ "token": "a1b2c3...96chars" }

// Response (200)
{
  "message": "Welcome to The Tower",
  "role": "ADMIN"
}

Error responses:

`GET /admin/admins`

List all active platform admins. Any platform admin can view.

// Response (200)
{
  "admins": [
    {
      "id": "uuid",
      "user_id": "uuid",
      "role": "SUPER_ADMIN",
      "granted_by": null,
      "granted_at": "2026-04-19T00:00:00Z",
      "email": "meekdenzo@gmail.com",
      "username": "meekdenzo",
      "display_name": null
    }
  ],
  "total": 2
}

`DELETE /admin/admins/:id`

Revoke a platform admin. SUPER_ADMIN only. Soft-deletes by setting revoked_at.

// Response (200)
{
  "message": "Platform admin access revoked",
  "revoked_user_id": "uuid"
}

Error responses:

Role Capabilities

Session TTL Impact

Platform admins receive shorter session TTLs for security:

Frontend Integration

Auth Store

The /me endpoint now returns platform_admin_role alongside is_privileged:

// $currentUser
{
  id: "uuid",
  email: "meekdenzo@gmail.com",
  is_privileged: true,
  platform_admin_role: "SUPER_ADMIN",  // new field
  // ...
}

Tower Routes

Navigation Gating

The Tower link in SideNav, UserMenu, and footer is conditionally rendered based on $currentUser?.is_privileged.

Seed Migration

The initial SUPER_ADMINs are seeded by email lookup (not hardcoded UUIDs), ensuring the migration survives database wipes:

INSERT INTO platform_admins (user_id, role)
SELECT id, 'SUPER_ADMIN'::platform_admin_role
FROM users
WHERE email IN ('meekdenzo@gmail.com', 'mallnline.dev@gmail.com')
ON CONFLICT (user_id) DO NOTHING;

Component State

The Team tab in +page.svelte uses the following Svelte 5 runes state:

File Reference

Related

• Workspaces & The Tower — Tower route architecture and Deck ↔ Tower separation
• User Listing API — Admin-only user management queries consumed by Tower
• Admin Analytics Dashboards — Revenue, Blog, Media, Search, Alerts analytics in The Tower
• Corporate Identity (SAML & SCIM) — Enterprise SSO and provisioning (complementary to platform admin provisioning)
• User Identity Resolution — Shared utility for resolving admin user IDs to display names across Tower and org dashboards