Skip to content

🔌 Epic: Configurable Plugins via Admin UI #1472

New issue
New issue
Open
Open
🔌 Epic: Configurable Plugins via Admin UI#1472
Labels
enhancementNew feature or request
@crivetimihai

Description

@crivetimihai
crivetimihai
opened on Nov 19, 2025

🔌 Epic: Configurable Plugins via Admin UI

Goal

Implement a comprehensive plugin configuration system in the Admin UI that enables administrators to enable/disable plugins, configure plugin-specific settings (e.g., PII patterns, deny lists, rate limits), and manage alerting preferences for each plugin—all without editing YAML files or restarting the gateway.

Why Now?

As MCP Gateway grows with production deployments and diverse plugin ecosystems, configuration management becomes a critical operational need:

  1. Operational Agility: Administrators need to modify plugin behavior in real-time without code deployments or service restarts
  2. User Experience: Editing YAML files and restarting services is error-prone and requires technical expertise
  3. Dynamic Policy Enforcement: Security policies, rate limits, and filters need to adapt to changing threats and business requirements
  4. Multi-Tenant Requirements: Different tenants/teams need different plugin configurations and policies
  5. Compliance & Audit: Configuration changes need to be tracked with audit trails for regulatory compliance
  6. Plugin Ecosystem Growth: As more plugins are developed, a unified configuration UI becomes essential
  7. Alert Integration: Plugins need configurable alerting to notify administrators of policy violations

By implementing a UI-driven configuration system, we enable non-technical administrators to manage complex plugin behaviors while maintaining audit trails and minimizing downtime.

📖 User Stories

US-1: Platform Admin - Enable/Disable Plugins via UI

As a Platform Administrator
I want to enable or disable plugins from the Admin UI
So that I can control plugin behavior without editing configuration files

Acceptance Criteria:

Given I navigate to /admin/plugins
Then I should see:
  - List of all registered plugins
  - Each plugin shows: name, description, status (enabled/disabled), version
  - Toggle switch to enable/disable each plugin
  - Status badge (green "ENABLED" or gray "DISABLED")

When I disable the "PIIFilterPlugin"
Then:
  - The toggle switch should update to "disabled" state
  - The status badge should change to gray "DISABLED"
  - An HTMX request should POST to /admin/plugins/pii_filter/disable
  - The plugin should immediately stop processing requests
  - A success message should appear: "PIIFilterPlugin disabled"
  - An alert should be created: "Plugin PIIFilterPlugin disabled by admin@example.com"
  - The change should be logged to audit trail

When I re-enable the "PIIFilterPlugin"
Then:
  - The toggle should update to "enabled" state
  - The status badge should change to green "ENABLED"
  - The plugin should immediately start processing requests
  - Configuration should persist across gateway restarts

Technical Requirements:

  • HTMX-powered toggle switches with optimistic UI updates
  • Backend: Update plugin status in database
  • Runtime: Dynamically update plugin manager without restart
  • Audit logging for all enable/disable actions
  • Rollback on error (if plugin fails to start)
US-2: Security Engineer - Configure PII Filter Patterns via UI

As a Security Engineer
I want to configure PII detection patterns from the Admin UI
So that I can adapt to new PII types without code changes

Acceptance Criteria:

Given I navigate to /admin/plugins/pii_filter/settings
When I see the current configuration:
  patterns:
    ssn: '\b\d{3}-\d{2}-\d{4}\b'
    email: '\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b'
    phone: '\b\d{3}-\d{3}-\d{4}\b'
  redaction_strategy: "redact"
  
Then I should be able to:
  - Add a new pattern: credit_card: '\b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b'
  - Edit existing patterns (regex in text input)
  - Delete patterns (with confirmation dialog)
  - Test patterns against sample text (live preview)
  - Change redaction strategy: "redact", "hash", "remove", "partial"
  - Set per-pattern sensitivity: "critical", "high", "medium", "low"

When I save the configuration
Then:
  - An HTMX request should POST to /admin/plugins/pii_filter/settings
  - The new configuration should be validated (regex syntax check)
  - If valid: Plugin should reload with new patterns immediately
  - If invalid: Error message should appear with validation details
  - Success message: "PII patterns updated successfully"
  - An alert should be created: "PIIFilterPlugin configuration updated"
  - The change should be logged to audit trail with before/after diff

Technical Requirements:

  • Form validation: regex syntax checking
  • Live preview: test patterns against sample text
  • Atomic updates: validate before applying
  • Hot reload: update plugin config without restart
  • Versioning: track configuration changes over time
  • Rollback: ability to revert to previous configuration
US-3: Operations Engineer - Configure Rate Limits per Plugin

As an Operations Engineer
I want to configure rate limits and throttling for plugins
So that I can prevent performance degradation and abuse

Acceptance Criteria:

Given I navigate to /admin/plugins/rate_limiter/settings
When I configure rate limits:
  rate_limits:
    global:
      requests_per_minute: 1000
      burst: 50
    per_user:
      requests_per_minute: 100
      burst: 10
    per_tool:
      "expensive-tool": 10
      "lightweight-tool": 200
  
Then I should be able to:
  - Set global rate limits (requests per minute, burst size)
  - Set per-user rate limits
  - Set per-tool rate limits (dropdown to select tool)
  - Enable/disable rate limiting
  - Set throttle response: "block" or "queue"
  - Configure alert thresholds (e.g., alert when 80% of limit reached)

When I save the configuration
Then:
  - The plugin should apply new limits immediately
  - Existing requests should continue under old limits
  - New requests should be evaluated under new limits
  - Alerts should be generated when thresholds exceeded

Technical Requirements:

  • Dynamic rate limit updates without restart
  • Sliding window or token bucket algorithm
  • Per-user, per-tool, per-tenant granularity
  • Integration with alert system
  • Metrics export (Prometheus)
US-4: Platform Admin - Configure Plugin Alert Settings

As a Platform Administrator
I want to configure alerting for each plugin
So that I am notified of policy violations and events

Acceptance Criteria:

Given I navigate to /admin/plugins/pii_filter/settings
When I configure alert settings:
  alerts:
    enabled: true
    min_severity: "warning"  # Only warning and critical
    throttle_interval: 300   # Max 1 alert per 5 minutes
    notification_channels: ["ui", "email", "webhook"]
    custom_message_template: "PII detected in {{tool_name}} by {{user_id}}"
    
Then I should be able to:
  - Enable/disable alerts for this plugin
  - Set minimum severity (info, warning, critical)
  - Set throttle interval (seconds)
  - Select notification channels (checkboxes: UI, Email, Webhook)
  - Customize alert message template (with variables)
  - Test alert generation (send test alert)

When I save the alert settings
Then:
  - The plugin should emit alerts according to new settings
  - Throttling should prevent alert storms
  - Alerts should route to configured channels
  - Test alert should appear in notification bell

Technical Requirements:

  • Integration with AlertService
  • Template rendering for custom messages
  • Per-plugin alert configuration
  • Alert testing and preview
  • Throttling and deduplication
US-5: Plugin Developer - Register Plugin Configuration Schema

As a Plugin Developer
I want to define a configuration schema for my plugin
So that the Admin UI can auto-generate configuration forms

Acceptance Criteria:

Given I am developing a custom plugin
When I define a configuration schema in my plugin class:

class MyCustomPlugin(Plugin):
    def get_config_schema(self) -> dict:
        return {
            "type": "object",
            "properties": {
                "threshold": {
                    "type": "integer",
                    "minimum": 0,
                    "maximum": 100,
                    "default": 50,
                    "title": "Detection Threshold",
                    "description": "Percentage threshold for triggering action"
                },
                "patterns": {
                    "type": "array",
                    "items": {"type": "string"},
                    "title": "Matching Patterns",
                    "description": "List of regex patterns to match"
                },
                "action": {
                    "type": "string",
                    "enum": ["block", "warn", "log"],
                    "default": "warn",
                    "title": "Action on Match"
                }
            },
            "required": ["threshold", "action"]
        }

Then the Admin UI should:
  - Auto-generate a configuration form at /admin/plugins/my_custom/settings
  - Render appropriate input types (number, text, select, array)
  - Show titles and descriptions as labels/help text
  - Validate input according to schema (min/max, required, enum)
  - Show validation errors inline
  - Support nested objects and arrays

Technical Requirements:

  • JSON Schema support for configuration definitions
  • Dynamic form generation from schema
  • Validation using JSON Schema validators
  • Support for common types: string, number, boolean, array, object, enum
  • Support for nested schemas
  • UI rendering with HTMX and Alpine.js
US-6: Compliance Officer - View Plugin Configuration Audit Trail

As a Compliance Officer
I want to view a complete history of plugin configuration changes
So that I can demonstrate compliance and investigate incidents

Acceptance Criteria:

Given I navigate to /admin/plugins/pii_filter/audit
Then I should see:
  - Paginated list of configuration changes (50 per page)
  - Each entry shows:
    - Timestamp
    - User who made the change
    - Action: "enabled", "disabled", "config_updated"
    - Before/after diff (JSON or YAML)
    - Reason/comment (if provided)
  - Filters: date range, user, action type
  - Export: Download as CSV/JSON

When I click on a configuration change
Then I should see:
  - Full before/after configuration (side-by-side diff)
  - Metadata: IP address, session ID, request ID
  - Related alerts generated after this change
  - Ability to revert to previous configuration (with confirmation)

Technical Requirements:

  • Configuration versioning in database
  • JSON diff generation for before/after comparison
  • Audit log with full metadata
  • Revert functionality with validation
  • Export for SIEM integration
US-7: Multi-Tenant Admin - Configure Plugins per Tenant

As a Multi-Tenant Administrator
I want to configure different plugin settings for different tenants
So that each organization has custom policies

Acceptance Criteria:

Given I have multiple tenants: "acme-corp", "globex", "initech"
When I navigate to /admin/tenants/acme-corp/plugins
Then I should be able to:
  - Override global plugin configuration for this tenant
  - Enable/disable plugins specifically for this tenant
  - Set tenant-specific PII patterns, rate limits, etc.
  - View effective configuration (tenant override + global defaults)

When a request comes from "acme-corp"
Then:
  - Plugins should use acme-corp's configuration
  - If no tenant override exists, fall back to global config
  - Alerts should be tagged with tenant_id

Technical Requirements:

  • Tenant-scoped plugin configuration
  • Configuration inheritance (tenant → global → default)
  • Effective configuration calculation
  • Multi-tenant isolation
  • Per-tenant audit trails

🏗 Architecture

Configuration Flow

sequenceDiagram
    participant Admin as Administrator
    participant UI as Admin UI
    participant API as API Endpoint
    participant ConfigSvc as ConfigService
    participant DB as Database
    participant PluginMgr as PluginManager
    participant Plugin as Plugin Instance
    participant AlertSvc as AlertService

    Admin->>UI: Navigate to /admin/plugins/pii_filter/settings
    UI->>API: GET /admin/plugins/pii_filter/config
    API->>ConfigSvc: get_plugin_config("pii_filter")
    ConfigSvc->>DB: SELECT config FROM plugin_configs WHERE plugin_name='pii_filter'
    DB-->>ConfigSvc: config JSON
    ConfigSvc-->>API: config object
    API-->>UI: Render form with current config

    Admin->>UI: Update patterns, change settings, click Save
    UI->>API: POST /admin/plugins/pii_filter/config {new_config}
    API->>ConfigSvc: validate_config(schema, new_config)
    
    alt Validation fails
        ConfigSvc-->>API: ValidationError
        API-->>UI: Show error messages
    else Validation succeeds
        ConfigSvc->>DB: INSERT INTO plugin_config_history (before, after)
        ConfigSvc->>DB: UPDATE plugin_configs SET config=new_config
        ConfigSvc->>PluginMgr: reload_plugin("pii_filter", new_config)
        PluginMgr->>Plugin: reload(new_config)
        Plugin-->>PluginMgr: reloaded successfully
        PluginMgr-->>ConfigSvc: success
        
        ConfigSvc->>AlertSvc: create_alert("PIIFilterPlugin config updated")
        
        ConfigSvc-->>API: success
        API-->>UI: Show success message + refresh UI
    end
Loading

Database Schema

-- Plugin configurations (current state)
CREATE TABLE plugin_configs (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    plugin_name VARCHAR(100) NOT NULL,
    tenant_id UUID REFERENCES tenants(id) ON DELETE CASCADE,  -- NULL for global config
    enabled BOOLEAN DEFAULT TRUE,
    config JSONB NOT NULL,
    schema JSONB,  -- JSON Schema for validation
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_by UUID REFERENCES users(id),
    
    UNIQUE(plugin_name, tenant_id),
    INDEX idx_plugin_name (plugin_name),
    INDEX idx_tenant_id (tenant_id)
);

-- Plugin configuration history (audit trail)
CREATE TABLE plugin_config_history (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    plugin_config_id UUID REFERENCES plugin_configs(id) ON DELETE CASCADE,
    plugin_name VARCHAR(100) NOT NULL,
    tenant_id UUID,
    action VARCHAR(50) NOT NULL,  -- enabled, disabled, config_updated
    config_before JSONB,
    config_after JSONB,
    changed_by UUID REFERENCES users(id),
    changed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    ip_address VARCHAR(45),
    session_id VARCHAR(100),
    reason TEXT,
    
    INDEX idx_plugin_name (plugin_name),
    INDEX idx_changed_at (changed_at),
    INDEX idx_changed_by (changed_by)
);

-- Plugin alert configurations (per-plugin alert settings)
CREATE TABLE plugin_alert_configs (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    plugin_config_id UUID REFERENCES plugin_configs(id) ON DELETE CASCADE,
    enabled BOOLEAN DEFAULT TRUE,
    min_severity VARCHAR(20) DEFAULT 'info',
    throttle_interval INTEGER DEFAULT 300,
    notification_channels JSONB DEFAULT '["ui"]',  -- ["ui", "email", "webhook"]
    custom_message_template TEXT,
    
    UNIQUE(plugin_config_id)
);

-- Plugin metadata (registered plugins and their schemas)
CREATE TABLE plugin_metadata (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    name VARCHAR(100) UNIQUE NOT NULL,
    kind VARCHAR(200) NOT NULL,  -- Python class path
    description TEXT,
    version VARCHAR(50),
    author VARCHAR(100),
    config_schema JSONB,  -- JSON Schema for auto-generating UI forms
    hooks JSONB,  -- List of hooks this plugin implements
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

📋 Implementation Tasks

Phase 1: Configuration Service ✅

  • ConfigService Implementation

    • Create mcpgateway/services/plugin_config_service.py
    • Implement PluginConfigService class with methods:
      • get_plugin_config(plugin_name, tenant_id=None)
      • update_plugin_config(plugin_name, config, tenant_id=None, user_id)
      • enable_plugin(plugin_name, tenant_id=None, user_id)
      • disable_plugin(plugin_name, tenant_id=None, user_id)
      • validate_config(schema, config)
      • get_effective_config(plugin_name, tenant_id) (tenant → global → default)
      • get_config_history(plugin_name, tenant_id=None, filters)
      • revert_to_version(history_id, user_id)
    • Integration with PluginManager for hot reload

  • Database Schema

    • Create Alembic migration for plugin_configs table
    • Create migration for plugin_config_history table
    • Create migration for plugin_alert_configs table
    • Create migration for plugin_metadata table
    • Add indexes for performance

  • ORM Models

    • Create models.PluginConfig
    • Create models.PluginConfigHistory
    • Create models.PluginAlertConfig
    • Create models.PluginMetadata
    • Add relationships

Phase 2: Plugin Manager Enhancement ✅

  • Hot Reload Support

    • Add reload_plugin(name, config) method to PluginManager
    • Unload plugin gracefully (finish in-flight requests)
    • Reinitialize plugin with new configuration
    • Validate plugin starts successfully
    • Rollback on failure

  • Configuration Schema Support

    • Add get_config_schema() method to Plugin base class
    • Parse JSON Schema definitions
    • Return default configuration if not overridden

  • Multi-Tenant Plugin Isolation

    • Load tenant-specific plugin configurations
    • Calculate effective config per request (tenant → global)
    • Cache effective configs per tenant

Phase 3: Admin UI - Plugin List Page ✅

  • Plugin List Page

    • Create templates/plugins/list.html
    • Display all registered plugins
    • Show: name, description, status, version, author
    • Enable/disable toggle switch per plugin
    • "Configure" button → navigate to settings page
    • Status badges (enabled/disabled)

  • Endpoints

    • GET /admin/plugins (render plugin list page)
    • GET /admin/plugins/data (HTMX partial for plugin rows)
    • POST /admin/plugins/{name}/enable (enable plugin)
    • POST /admin/plugins/{name}/disable (disable plugin)

  • Real-Time Status

    • Show if plugin is currently processing requests
    • Show plugin health status (healthy, degraded, failed)
    • Show metrics: requests processed, errors, latency

Phase 4: Admin UI - Plugin Settings Page ✅

  • Dynamic Form Generation

    • Create templates/plugins/settings.html
    • Parse JSON Schema from get_config_schema()
    • Auto-generate form inputs based on schema types:
      • String → text input
      • Integer/Number → number input
      • Boolean → checkbox
      • Enum → select dropdown
      • Array → dynamic list (add/remove items)
      • Object → nested fieldset
    • Show titles as labels, descriptions as help text
    • Pre-populate with current configuration values

  • Form Validation

    • Client-side validation (Alpine.js)
    • Server-side validation (JSON Schema validator)
    • Inline error messages per field
    • Form-level validation summary

  • Configuration Testing

    • "Test Configuration" button
    • For PII filter: text area to test patterns
    • For rate limiter: simulate request load
    • Live preview of plugin behavior

  • Endpoints

    • GET /admin/plugins/{name}/settings (render settings page)
    • GET /admin/plugins/{name}/config (get current config as JSON)
    • POST /admin/plugins/{name}/config (update config)
    • POST /admin/plugins/{name}/test (test configuration)

Phase 5: Admin UI - Alert Configuration per Plugin ✅

  • Alert Settings Section

    • Add alert config section to templates/plugins/settings.html
    • Enable/disable alerts checkbox
    • Min severity dropdown (info, warning, critical)
    • Throttle interval number input (seconds)
    • Notification channels checkboxes (UI, Email, Webhook)
    • Custom message template text area

  • Alert Testing

    • "Send Test Alert" button
    • Generate test alert for this plugin
    • Show preview in notification bell

  • Endpoints

    • GET /admin/plugins/{name}/alerts (get alert config)
    • PUT /admin/plugins/{name}/alerts (update alert config)
    • POST /admin/plugins/{name}/alerts/test (send test alert)

Phase 6: Admin UI - Configuration Audit Trail ✅

  • Audit Trail Page

    • Create templates/plugins/audit.html
    • Paginated list of config changes
    • Show: timestamp, user, action, diff summary
    • Filters: date range, user, action type
    • Export: CSV/JSON download

  • Diff Viewer

    • Side-by-side diff view (before/after)
    • Highlight changed fields
    • JSON/YAML formatting

  • Revert Functionality

    • "Revert to this version" button per history entry
    • Confirmation dialog with diff preview
    • Apply reverted config
    • Log revert action in audit trail

  • Endpoints

    • GET /admin/plugins/{name}/audit (render audit page)
    • GET /admin/plugins/{name}/audit/data (HTMX partial for history rows)
    • POST /admin/plugins/{name}/audit/{history_id}/revert (revert to version)

Phase 7: Built-in Plugin Configurations ✅

  • PII Filter Plugin

    • Implement get_config_schema() in PIIFilterPlugin
    • Schema for patterns (object with pattern names and regexes)
    • Schema for redaction_strategy (enum)
    • Schema for alert settings
    • Load config from database instead of YAML

  • Deny Filter Plugin

    • Implement get_config_schema() in DenyFilterPlugin
    • Schema for deny_patterns (array of regexes)
    • Schema for action (enum: block, warn, log)
    • Load config from database

  • Rate Limiter Plugin

    • Implement get_config_schema() in RateLimiterPlugin
    • Schema for global, per-user, per-tool limits
    • Schema for throttle response (enum)
    • Load config from database

  • Resource Filter Plugin

    • Implement get_config_schema() in ResourceFilterPlugin
    • Schema for allowed/denied resource patterns
    • Load config from database

Phase 8: Multi-Tenant Support ✅

  • Tenant-Specific Configuration UI

    • Add plugin config section to tenant management page
    • Navigate to /admin/tenants/{id}/plugins
    • Show global config vs tenant override
    • Enable per-tenant overrides

  • Effective Configuration Display

    • Show "Effective Configuration" (computed tenant + global)
    • Highlight overridden fields
    • "Reset to global" button for overrides

  • Endpoints

    • GET /admin/tenants/{id}/plugins/{name}/config
    • POST /admin/tenants/{id}/plugins/{name}/config
    • DELETE /admin/tenants/{id}/plugins/{name}/config (remove override)

Phase 9: Testing ✅

  • Unit Tests

    • Test PluginConfigService CRUD operations
    • Test configuration validation (JSON Schema)
    • Test effective config calculation (tenant → global)
    • Test hot reload mechanism
    • Test revert functionality
    • Test audit trail logging

  • Integration Tests

    • Test plugin enable/disable via API
    • Test configuration updates and hot reload
    • Test tenant-specific configurations
    • Test alert config integration
    • Test configuration revert

  • UI Tests

    • Playwright tests for plugin list page
    • Test enable/disable toggle
    • Test settings form rendering and submission
    • Test validation errors
    • Test audit trail page

Phase 10: Documentation ✅

  • User Guide

    • Create docs/docs/manage/plugin-configuration.md
    • Document plugin management UI
    • Document configuration settings per plugin
    • Document alert configuration
    • Document audit trail and revert

  • Developer Guide

    • Document get_config_schema() contract
    • Document JSON Schema support
    • Document how to make plugins configurable
    • Example: creating a configurable plugin

  • API Documentation

    • OpenAPI spec for plugin config endpoints
    • Example API calls

Phase 11: Quality & Polish ✅

  • Code Quality

    • Run make autoflake isort black
    • Run make flake8 and fix issues
    • Run make pylint and address warnings
    • Pass make verify

  • Performance

    • Cache effective configs per tenant
    • Optimize database queries for config loading
    • Minimize plugin reload downtime (<1 second)

⚙️ Configuration Example

JSON Schema for PII Filter Plugin

class PIIFilterPlugin(Plugin):
    def get_config_schema(self) -> dict:
        return {
            "type": "object",
            "title": "PII Filter Configuration",
            "description": "Configure patterns to detect and redact personally identifiable information",
            "properties": {
                "patterns": {
                    "type": "object",
                    "title": "PII Patterns",
                    "description": "Regular expressions for detecting PII",
                    "additionalProperties": {
                        "type": "string",
                        "format": "regex"
                    },
                    "default": {
                        "ssn": r'\b\d{3}-\d{2}-\d{4}\b',
                        "email": r'\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b',
                        "phone": r'\b\d{3}-\d{3}-\d{4}\b'
                    }
                },
                "redaction_strategy": {
                    "type": "string",
                    "enum": ["redact", "hash", "remove", "partial"],
                    "default": "redact",
                    "title": "Redaction Strategy",
                    "description": "How to redact detected PII"
                },
                "case_sensitive": {
                    "type": "boolean",
                    "default": false,
                    "title": "Case Sensitive Matching"
                },
                "scan_requests": {
                    "type": "boolean",
                    "default": true,
                    "title": "Scan Requests",
                    "description": "Apply PII detection to incoming requests"
                },
                "scan_responses": {
                    "type": "boolean",
                    "default": true,
                    "title": "Scan Responses",
                    "description": "Apply PII detection to outgoing responses"
                }
            },
            "required": ["patterns", "redaction_strategy"]
        }

Database Representation

INSERT INTO plugin_configs (plugin_name, enabled, config, schema) VALUES (
    'pii_filter',
    true,
    '{
        "patterns": {
            "ssn": "\\b\\d{3}-\\d{2}-\\d{4}\\b",
            "email": "\\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Z|a-z]{2,}\\b",
            "credit_card": "\\b\\d{4}[\\s-]?\\d{4}[\\s-]?\\d{4}[\\s-]?\\d{4}\\b"
        },
        "redaction_strategy": "hash",
        "scan_requests": true,
        "scan_responses": true
    }',
    '{...JSON Schema...}'
);

INSERT INTO plugin_alert_configs (plugin_config_id, enabled, min_severity, throttle_interval, notification_channels) VALUES (
    (SELECT id FROM plugin_configs WHERE plugin_name='pii_filter'),
    true,
    'warning',
    300,
    '["ui", "email"]'
);

✅ Success Criteria

  • Plugin list page displays all plugins with status
  • Enable/disable toggles work without restart
  • Settings page auto-generates forms from JSON Schema
  • Configuration updates apply immediately (hot reload)
  • Validation errors display inline
  • Alert configuration works per plugin
  • Audit trail tracks all configuration changes
  • Revert functionality restores previous configs
  • Multi-tenant configuration overrides work
  • 80%+ test coverage
  • Documentation complete
  • Code passes make verify

🏁 Definition of Done

  • PluginConfigService implemented
  • Database schema migrated
  • Hot reload mechanism working
  • Plugin list UI complete
  • Plugin settings UI with dynamic forms
  • Alert configuration UI per plugin
  • Audit trail UI complete
  • Revert functionality working
  • Multi-tenant support implemented
  • Built-in plugins use DB config
  • 80%+ unit test coverage
  • Integration tests passing
  • Playwright UI tests passing
  • Documentation complete
  • Code quality checks passing

📝 Additional Notes

🔹 Hot Reload: Plugins reload without downtime by gracefully finishing in-flight requests

🔹 JSON Schema: Auto-generates UI forms, reducing development effort for new plugins

🔹 Audit Trail: Full history of configuration changes for compliance

🔹 Multi-Tenant: Different organizations can have different plugin configurations

🔹 Alert Integration: Seamless integration with alerting system

🔹 Validation: Client and server-side validation prevents invalid configurations

🔹 Testing: Live preview and testing features help administrators validate configs

🔗 Related Issues

📚 References

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions