diff --git a/IMPACT_EXPLANATION.md b/IMPACT_EXPLANATION.md deleted file mode 100644 index fcef0fa7..00000000 --- a/IMPACT_EXPLANATION.md +++ /dev/null @@ -1,245 +0,0 @@ -# Impact Explanation: Config Schema Validation Fixes - -## Current Problem (Before Fixes) - -### What Users Experience Now - -**Scenario**: User wants to configure a plugin (e.g., hockey-scoreboard) - -1. User opens web interface → Plugins tab → hockey-scoreboard configuration -2. User changes some settings (e.g., favorite teams, display duration) -3. User clicks "Save Configuration" button -4. **ERROR**: "Configuration validation failed: Missing required field: 'enabled'" -5. **RESULT**: Configuration changes are NOT saved -6. User is frustrated - can't save their configuration - -**Why This Happens**: -- Plugin schema has `"required": ["enabled"]` -- `enabled` field is system-managed (controlled by PluginManager/enable toggle) -- Config doesn't have `enabled` field (it's managed separately) -- Validation fails because `enabled` is required but missing - -### Real-World Impact - -- **186 validation errors** across all 20 plugins -- **ALL plugins** currently fail to save configs via web interface -- Users cannot configure plugins through the UI -- This is a **blocking issue** for plugin configuration - ---- - -## Priority 1 Fix: Remove Core Properties from Required Array - -### What Changes Technically - -**File**: `src/plugin_system/schema_manager.py` - -**Change**: After injecting core properties (`enabled`, `display_duration`, `live_priority`) into schema properties, also remove them from the `required` array. - -**Before**: -```python -# Core properties added to properties (allowed) -enhanced_schema["properties"]["enabled"] = {...} - -# But still in required array (validation fails if missing) -enhanced_schema["required"] = ["enabled", ...] # ❌ Still requires enabled -``` - -**After**: -```python -# Core properties added to properties (allowed) -enhanced_schema["properties"]["enabled"] = {...} - -# Removed from required array (not required for validation) -enhanced_schema["required"] = [...] # ✅ enabled removed, validation passes -``` - -### Why This Is Correct - -- `enabled` is managed by PluginManager (system-level concern) -- User doesn't set `enabled` in plugin config form (it's a separate toggle) -- Config validation should check user-provided config, not system-managed fields -- Core properties should be **allowed** but not **required** - -### User Experience After Fix - -**Scenario**: User configures hockey-scoreboard plugin - -1. User opens web interface → Plugins tab → hockey-scoreboard configuration -2. User changes settings (favorite teams, display duration) -3. User clicks "Save Configuration" button -4. **SUCCESS**: Configuration saves without errors -5. Changes are persisted and plugin uses new configuration - -**Impact**: -- ✅ All 20 plugins can now save configs successfully -- ✅ ~150 validation errors eliminated (all "enabled" related) -- ✅ Users can configure plugins normally -- ✅ This is the **primary fix** that unblocks plugin configuration - -### Technical Details - -- Issue count: 186 → ~30-40 (most issues resolved) -- No breaking changes - only affects validation logic -- Backward compatible - configs that work will continue to work -- Makes validation logic match the actual architecture - ---- - -## Priority 2 Fix: Verify Default Merging Logic - -### What This Addresses - -Some plugins have required fields that have default values in their schemas. For example: -- `calendar` plugin requires `credentials_file` but schema provides default: `"credentials.json"` -- When user saves config without this field, the default should be applied automatically -- Then validation passes because the field is present (with default value) - -### Current Behavior - -The code already has default merging logic: -```python -defaults = schema_mgr.generate_default_config(plugin_id, use_cache=True) -plugin_config = schema_mgr.merge_with_defaults(plugin_config, defaults) -``` - -**But audit shows some plugins still fail**, which suggests either: -1. Default merging isn't working correctly for all cases, OR -2. Some required fields don't have defaults in schemas (schema design issue) - -### What We'll Verify - -1. Check if `merge_with_defaults()` handles nested objects correctly -2. Verify defaults are applied before validation runs -3. Test with problematic plugins to see why they still fail -4. Fix any issues found OR identify that schemas need defaults added - -### User Experience Impact - -**If defaults are working correctly**: -- Users don't need to manually add every field -- Fields with defaults "just work" automatically -- Easier plugin configuration - -**If defaults aren't working**: -- After fix, plugins with schema defaults will validate correctly -- Fewer manual field entries required -- Better user experience - -### Technical Details - -- Issue count: ~30-40 → ~5-10 (after Priority 1) -- Addresses remaining validation failures -- May involve schema updates if defaults are missing -- Improves robustness of config system - ---- - -## Priority 3 Fix: Calendar Plugin Cleanup - -### What This Addresses - -Calendar plugin has configuration fields that don't match its schema: -- `show_all_day` in config, but schema defines `show_all_day_events` (field name mismatch) -- `date_format` and `time_format` in config but not in schema (deprecated fields) - -### Current Problems - -1. **Field name mismatch**: `show_all_day` vs `show_all_day_events` - - Schema filtering removes `show_all_day` during save - - User's setting for all-day events doesn't actually work - - This is a **bug** where the setting is ignored - -2. **Deprecated fields**: `date_format` and `time_format` - - Not used in plugin code - - Confusing to see in config - - Schema filtering removes them anyway (just creates warnings) - -### What We'll Fix - -1. **Fix field name**: Rename `show_all_day` → `show_all_day_events` in config - - Makes config match schema - - Fixes bug where all-day events setting doesn't work - -2. **Remove deprecated fields**: Remove `date_format` and `time_format` from config - - Cleans up config file - - Removes confusion - - No functional impact (fields weren't used) - -### User Experience Impact - -**Before**: -- User sets "show all day events" = true -- Setting doesn't work (field name mismatch) -- User confused why setting isn't applied - -**After**: -- User sets "show all day events" = true -- Setting works correctly (field name matches schema) -- Config is cleaner and matches schema - -### Technical Details - -- Issue count: ~5-10 → ~3-5 (after Priority 1 & 2) -- Fixes a bug (show_all_day_events not working) -- Cleanup/improvement, not critical -- Only affects calendar plugin - ---- - -## Summary: Real-World Impact - -### Before All Fixes - -**User tries to configure any plugin**: -- ❌ Config save fails with validation errors -- ❌ Cannot configure plugins via web interface -- ❌ 186 validation errors across all plugins -- ❌ System is essentially broken for plugin configuration - -### After Priority 1 Fix - -**When configuring a plugin**: -- ✅ Config saves successfully for most plugins -- ✅ Can configure plugins via web interface -- ✅ ~150 errors resolved (enabled field issues) -- ✅ System is functional for plugin configuration - -**Remaining issues**: ~30-40 validation errors -- Mostly fields without defaults that need user input -- Still some plugins that can't save (but most work) - -### After Priority 2 Fix - -**During plugin configuration**: -- ✅ Config saves successfully for almost all plugins -- ✅ Defaults applied automatically (easier configuration) -- ✅ ~30-40 errors → ~5-10 errors -- ✅ System is robust and user-friendly - -**Remaining issues**: ~5-10 edge cases -- Complex validation scenarios -- Possibly some schema design issues - -### After Priority 3 Fix - -**All plugins**: -- ✅ Configs match schemas exactly -- ✅ No confusing warnings -- ✅ Calendar plugin bug fixed (show_all_day_events works) -- ✅ ~3-5 remaining edge cases only -- ✅ System is clean and fully functional - ---- - -## Bottom Line - -**Current State**: Plugin configuration saving is broken (186 errors, all plugins fail) - -**After Fixes**: Plugin configuration saving works correctly (3-5 edge cases remain, all plugins functional) - -**User Impact**: Users can configure plugins successfully instead of getting validation errors - -**Technical Impact**: Validation logic correctly handles system-managed fields and schema defaults - - diff --git a/MERGE_CONFLICT_RESOLUTION_PLAN.md b/MERGE_CONFLICT_RESOLUTION_PLAN.md deleted file mode 100644 index c453f087..00000000 --- a/MERGE_CONFLICT_RESOLUTION_PLAN.md +++ /dev/null @@ -1,188 +0,0 @@ -# Merge Conflict Resolution Plan: plugins → main - -## Overview -This document outlines the plan to resolve merge conflicts when merging the `plugins` branch into `main`. The conflicts occur because the plugins branch refactored the architecture from built-in managers to a plugin-based system. - -## Conflicted Files - -### 1. `src/clock.py` -**Status**: EXISTS in `main`, DELETED in `plugins` - -**Reason for Conflict**: -- In `main`: Clock functionality is implemented as a built-in manager (`src/clock.py`) -- In `plugins`: Clock functionality has been migrated to a plugin (`plugins/clock-simple/manager.py`) - -**Resolution Strategy**: -- ✅ **DELETE** `src/clock.py` from `main` when merging -- The plugin version at `plugins/clock-simple/manager.py` replaces this file -- Functionality is preserved in the plugin architecture - -**Action Required**: -```bash -git rm src/clock.py -``` - -**Verification**: -- Ensure `plugins/clock-simple/` plugin exists and works -- Verify clock functionality works via the plugin system - ---- - -### 2. `src/news_manager.py` -**Status**: EXISTS in `main`, DELETED in `plugins` - -**Reason for Conflict**: -- In `main`: News functionality is implemented as a built-in manager (`src/news_manager.py`) -- In `plugins`: News functionality has been migrated to a plugin (`plugins/ledmatrix-news/manager.py`) - -**Resolution Strategy**: -- ✅ **DELETE** `src/news_manager.py` from `main` when merging -- The plugin version at `plugins/ledmatrix-news/manager.py` replaces this file -- Functionality is preserved in the plugin architecture - -**Action Required**: -```bash -git rm src/news_manager.py -``` - -**Verification**: -- Ensure `plugins/ledmatrix-news/` plugin exists and works -- Verify news functionality works via the plugin system - ---- - -### 3. `README.md` -**Status**: SIGNIFICANTLY DIFFERENT in both branches - -**Main Differences**: - -| Aspect | `main` branch | `plugins` branch | -|--------|--------------|------------------| -| Introduction | Has detailed "Core Features" section with screenshots | Has "Plugins Version is HERE!" introduction | -| Architecture | Describes built-in managers | Describes plugin-based architecture | -| Website Link | Includes link to website write-up | Removed website link, added ko-fi link | -| Content Focus | Feature showcase with images | Plugin system explanation | - -**Resolution Strategy**: -- ✅ **KEEP** `plugins` branch version as the base (it's current and accurate for plugin architecture) -- ⚠️ **CONSIDER** preserving valuable content from `main`: - - The detailed "Core Features" section with screenshots might be valuable for documentation - - The website write-up link might be worth preserving - - However, since plugins branch is more current and accurate, prefer plugins version - -**Recommended Approach**: -1. Keep plugins branch README.md as-is (it's current and accurate) -2. The old "Core Features" section in main is outdated for the plugin architecture -3. If website link is important, it can be added back to plugins version separately - -**Action Required**: -```bash -# Accept plugins branch version -git checkout --theirs README.md -# OR manually review and merge, keeping plugins version as base -``` - -**Verification**: -- README.md accurately describes the plugin architecture -- All installation and configuration instructions are current -- Links are working - ---- - -## Step-by-Step Resolution Process - -### Step 1: Checkout main branch and prepare for merge -```bash -git checkout main -git fetch origin -git merge origin/plugins --no-commit --no-ff -``` - -### Step 2: Resolve file deletion conflicts -```bash -# Remove files that were migrated to plugins -git rm src/clock.py -git rm src/news_manager.py -``` - -### Step 3: Resolve README.md conflict -```bash -# Option A: Accept plugins version (recommended) -git checkout --theirs README.md - -# Option B: Manually review and merge -# Edit README.md to combine best of both if needed -``` - -### Step 4: Verify no references to deleted files -```bash -# Check if any code references the deleted files -grep -r "from src.clock import" . -grep -r "from src.news_manager import" . -grep -r "import src.clock" . -grep -r "import src.news_manager" . - -# If found, these need to be updated to use plugins instead -``` - -### Step 5: Test the resolved merge -```bash -# Verify plugins are loaded correctly -python3 -c "from src.plugin_system.plugin_manager import PluginManager; print('OK')" - -# Check that clock-simple plugin exists -ls -la plugins/clock-simple/ - -# Check that ledmatrix-news plugin exists -ls -la plugins/ledmatrix-news/ -``` - -### Step 6: Complete the merge -```bash -git add . -git commit -m "Merge plugins into main: Remove deprecated managers, keep plugin-based README" -``` - ---- - -## Verification Checklist - -- [ ] `src/clock.py` is deleted (functionality in `plugins/clock-simple/`) -- [ ] `src/news_manager.py` is deleted (functionality in `plugins/ledmatrix-news/`) -- [ ] `README.md` reflects plugin architecture (plugins branch version) -- [ ] No import statements reference deleted files -- [ ] Clock plugin works correctly -- [ ] News plugin works correctly -- [ ] All tests pass (if applicable) -- [ ] Documentation is accurate - ---- - -## Notes - -1. **No Code Changes Required**: The deletions are safe because: - - Clock functionality exists in `plugins/clock-simple/manager.py` - - News functionality exists in `plugins/ledmatrix-news/manager.py` - - The plugin system loads these automatically - -2. **README.md Decision**: Keeping plugins version is recommended because: - - It accurately describes the current plugin-based architecture - - The old "Core Features" section describes the old architecture - - Users need current installation/configuration instructions - -3. **Potential Issues**: - - If any code in `main` still imports these files, those imports need to be removed - - Configuration references to old managers may need updating - - Documentation references may need updating - ---- - -## Related Files to Check (Not Conflicted but Related) - -These files might reference the deleted managers and should be checked: - -- `display_controller.py` - May have references to Clock or NewsManager -- `config/config.json` - May have config sections for clock/news_manager -- Any test files that might test these managers -- Documentation files that reference these managers - diff --git a/DEVELOPMENT.md b/docs/DEVELOPMENT.md similarity index 100% rename from DEVELOPMENT.md rename to docs/DEVELOPMENT.md diff --git a/MIGRATION_GUIDE.md b/docs/MIGRATION_GUIDE.md similarity index 100% rename from MIGRATION_GUIDE.md rename to docs/MIGRATION_GUIDE.md diff --git a/plugins/soccer-scoreboard b/plugins/soccer-scoreboard index b8d4ce12..e22a16da 160000 --- a/plugins/soccer-scoreboard +++ b/plugins/soccer-scoreboard @@ -1 +1 @@ -Subproject commit b8d4ce12721910cc24dab77ed78c774690b2e9dd +Subproject commit e22a16da38606f232bc6cd67f9fc102ab0cca9ca diff --git a/web_interface/static/v3/plugins_manager.js b/web_interface/static/v3/plugins_manager.js index 7702addf..808714fb 100644 --- a/web_interface/static/v3/plugins_manager.js +++ b/web_interface/static/v3/plugins_manager.js @@ -1385,7 +1385,7 @@ function renderInstalledPlugins(plugins) { data-action="configure"> Configure -