?
TRCKR-221
web bug settings
Created: 2025-12-09 Updated: 2025-12-16
Relationships Loading...
Attachments
Loading...
Comments (2)
agent · 2025-12-10
**Additional Fix for Production:** After deploying the initial fix, discovered that existing production databases didn't have the settings table (added in TRCKR-197). This caused 'no such table: settings' errors. **Root Cause:** The _ensure_server_tables() migration function in server/database.py was only creating server-specific sync tables (sync_history, sync_snapshots) but not the settings table. **Solution:** Updated server/database.py line 52-70 to ensure settings table is created when the server starts: - Added SETTINGS_TABLE import - Added conn.execute(SETTINGS_TABLE) before sync table migrations **Verification:** - Deployed to production (commit 522f75c) - Tested API endpoints successfully: - PUT /api/settings/test.production returns 200 OK - GET /api/settings/test.production returns saved value - Settings modal should now work correctly on production server The fix automatically migrates existing databases without requiring manual intervention.
agent · 2025-12-10
Fixed the settings modal save functionality. **Root Cause:** The issue was in server/database.py line 84-96. The get_db() function was using @contextmanager decorator to create a synchronous generator context manager, but FastAPI's dependency injection system expects either a simple callable or an async context manager. When FastAPI tried to use this in an async context, it caused an AttributeError: '_GeneratorContextManager' object has no attribute 'throw'. **Changes Made:** 1. server/database.py: - Removed @contextmanager decorator from get_db() (line 84) - Converted get_db() to a simple function that returns the shared LocalStore instance (lines 84-90) - Removed unused imports (contextmanager, Generator) 2. tests/test_settings_web.py (new file): - Added comprehensive tests for settings API endpoints - test_get_settings_api: Verifies GET /api/settings works - test_update_setting_api: Verifies PUT /api/settings/{key} works - test_update_multiple_settings: Simulates the saveSettings() JavaScript function behavior - test_settings_modal_html: Verifies the settings modal HTML renders correctly **Testing:** - All new tests pass (4/4) - Verified API works with curl: - PUT /api/settings/issue.default.assignee returns 200 OK with updated value - GET /api/settings/issue.default.assignee returns saved value - The settings modal JavaScript (saveSettings() function) now works correctly because the API endpoints are functional **Files Modified:** - /private/tmp/trckr-TRCKR-221/server/database.py (lines 7-8, 84-90) - /private/tmp/trckr-TRCKR-221/tests/test_settings_web.py (new file, 106 lines)