Add TypeScript interfaces and API methods for new update system:
**New Types:**
- UpdatePlan: Deployment-specific update plan with canAutoUpdate flag
- UpdateHistoryEntry: Complete audit log entry with all metadata
**New API Methods:**
- getUpdatePlan(version, channel?) - Get deployment-specific update plan
- getUpdateHistory(limit?, status?) - List update history with filters
- getUpdateHistoryEntry(eventId) - Get specific history entry details
These types match the backend Go structs and enable frontend
integration with the adapter-based update system.
Next: Implement UI components (confirmation modal, progress modal,
update banner enhancements, settings history panel).
Wire up the adapter-based update system to HTTP API:
**Enhanced UpdateHandlers:**
- Initialize UpdateHistory and UpdaterRegistry
- Register all deployment adapters (systemd, proxmoxve, docker, aur)
- Handlers now have access to history and updater registry
**New API Endpoints:**
- GET /api/updates/plan?version=X - Get update plan for deployment
* Returns canAutoUpdate, instructions, prerequisites, estimated time
* Deployment-specific based on detected type
- GET /api/updates/history?limit=N&status=X - List update history
* Supports filtering by status (success/failed/in_progress)
* Returns audit log entries with full metadata
- GET /api/updates/history/entry?id=X - Get specific history entry
* Retrieve detailed information about past update
**Existing Endpoints Still Work:**
- GET /api/updates/check - Check for available updates
- POST /api/updates/apply - Apply update (legacy manager)
- GET /api/updates/status - Get current update status
The system now supports both:
- Legacy update flow (existing install.sh wrapper in manager.go)
- New adapter-based flow (prepared for frontend integration)
Next: Frontend components to consume new endpoints.
Add infrastructure for deployment-agnostic update management:
**Update History (Audit Log):**
- JSONL-based audit log (/var/lib/pulse/update-history.jsonl)
- Tracks all update attempts with full metadata
- In-memory cache for fast queries
- Schema designed for future DB migration
**Updater Interface:**
- Defines contract for deployment-specific update logic
- SupportsApply(), PrepareUpdate(), Execute(), Rollback()
- Registry pattern for managing multiple adapters
- Progress callbacks for real-time UI updates
**Adapters Implemented:**
- InstallShAdapter: Wraps install.sh (systemd/LXC)
* Full automation support
* Captures stdout/stderr to log files
* Parses backup paths from output
* Maintains install.sh as single source of truth
- DockerUpdater: Instruction-only (manual)
- AURUpdater: Instruction-only (package manager)
Key design decisions:
- install.sh remains unchanged (backward compatible)
- All update mechanisms funnel through adapters
- Audit log records all updates (manual + automated)
- Thin wrapper approach - no logic duplication
Next: Wire up API endpoints and frontend integration.
Implement smart update checking that shows appropriate updates based on user's current version:
- RC users now see both newer RC releases AND newer stable releases
- Stable users continue to see only stable releases (RCs filtered out)
- Both channels use version-aware filtering (only show updates > current version)
Key changes:
- Modified getLatestReleaseForChannel to accept currentVer parameter
- Removed /releases/latest shortcut; both channels now fetch all releases
- RC channel tracks both newest RC and newest stable, returns highest
- Stable channel filters prereleases and returns first stable > currentVer
- Added comprehensive test suite with 15 test cases
Respects semver ordering where 4.22.0 > 4.22.0-rc.3 per RFC.
Consulted with Codex for architectural direction.
Remove PMG instances from the Overview (dashboard) page to keep it
focused solely on PVE resources (VMs and containers). This provides
better separation of concerns, with each Proxmox product type having
its dedicated view:
- Overview tab: PVE nodes, VMs, and containers
- Mail Gateway tab: PMG instances with detailed metrics
- Storage tab: Storage resources
- Backups tab: PBS and backup data
Changes:
- Remove pmgInstances prop from NodeSummaryTable component
- Remove PMG type checks and rendering logic from node table
- Update UnifiedNodeSelector to match new interface
- Clean up PMG-related imports and type definitions
Add comprehensive PMG monitoring with mail statistics, queue depth tracking,
spam distribution analysis, and quarantine monitoring. Includes full discovery
support and UI consistency improvements across all Proxmox products.
Backend:
- Add pkg/pmg package with complete API client for PMG operations
- Implement mail statistics collection (inbound/outbound, spam, virus, bounces)
- Add queue depth monitoring (active, deferred, hold, incoming queues)
- Support spam score distribution and quarantine totals
- Add PMG-specific discovery logic to differentiate from PVE on port 8006
- Extend mock data generator with realistic PMG instances and metrics
- Add PMG node configuration support in config system
Frontend:
- Create MailGateway.tsx component with detailed PMG dashboard
- Display mail flow statistics with time-series charts
- Show queue depth with color-coded warnings (>50 messages or >30min age)
- Add spam distribution histogram and quarantine status
- Support cluster node status with individual queue monitoring
- Add PMG to network discovery with purple branding and mail icon
- Implement conditional navigation (hide PMG tab when no instances configured)
- Standardize discovery UI controls across PVE/PBS/PMG settings pages
API:
- Add /api/config/pmg endpoints for node configuration
- Support PMG-specific monitoring toggles (mail stats, queues, quarantine)
- Extend system settings with PMG configuration options
Discovery:
- Detect PMG vs PVE on shared port 8006 using /api2/json/statistics/mail endpoint
- Return 'pmg' type for mail gateway servers in discovery results
- Update DiscoveryModal to display PMG servers with appropriate styling
This completes ecosystem monitoring support for all three Proxmox products:
Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
- Add collapsible toggle for alert delay settings row to reduce visual clutter
- Match delay input styling to global threshold inputs (w-16, text-sm)
- Auto-clear delay override when value matches default to avoid confusion
- Remove unnecessary clear button - users can clear by emptying the field
- Simplify placeholder from "5s" to "5" for clarity
Add support for Authorization: Bearer <token> header as a fallback
for environments that strip custom headers like X-API-Token. Docker
agent now sends both headers for maximum compatibility.
- Add explicit typing for threshold records to handle undefined values
- Add temperature and docker threshold support to alert types
- Implement global toggle to disable all docker container alerts
- Add test coverage for docker container toggle behavior
- Add concurrency test for multi-instance node updates
Implement tri-state offline alert configuration (Off/Warning/Critical) for VMs, containers, and Docker containers with individual severity overrides and visual badge breakdown in alerts tab.
Changes:
- Add poweredOffSeverity field to resource models and override types
- Implement tri-state buttons (Off/Warn/Crit) in ResourceTable
- Add separate critical/warning badge counts in alerts tab
- Support per-resource severity overrides with proper defaults
- Include alert delay configuration column in thresholds table
- Update backend to honor per-resource severity levels
- Add proper state persistence in raw override config
activeAlerts from websocket store is a SolidJS Store proxy, not a plain
Record. Spread it to plain object before passing to getAlertStyles to
prevent 't is not a function' error.
Fix 'Cannot read properties of undefined (reading some)' error by
adding safety check before calling .some() on groupedContainers.
The error occurred when groupedContainers() returned undefined in edge
cases, causing .some() to fail. Now explicitly checking for truthy
value and non-empty array before calling .some().
rcourtman