## Database Migration Completed **Problem Found:** The previous fix (commit dfcba39) only updated the Pydantic model in server/models.py to include 'backlog' and 'cancelled' statuses, but the SQLite database CHECK constraint was never migrated. The production database still had the old constraint: ```sql CHECK (status IN ('triage', 'todo', 'in-progress', 'blocked', 'in-review', 'done', 'archived')) ``` **Changes Made:** 1. **server/database.py** (lines 98-212): Added `_migrate_issues_status_constraint()` migration function that: - Detects if migration is needed by checking for 'backlog' and 'cancelled' in the existing schema - Recreates the issues table with the new CHECK constraint (SQLite requires table recreation to modify constraints) - Preserves all existing data during migration - Recreates all 7 indexes on the issues table - Is idempotent - can be run safely multiple times 2. **client/migration.py** (line 190-196): Updated `migrate_issues()` to use centralized status definitions from statuses.py instead of hardcoded values, preventing similar issues in JSON-to-SQLite migrations. 3. **tests/test_database_migration.py** (new file): Added comprehensive test suite with 5 tests: - test_migration_updates_constraint: Verifies constraint accepts new statuses - test_migration_preserves_existing_data: Verifies all data preserved - test_migration_recreates_indexes: Verifies all indexes exist - test_migration_is_idempotent: Verifies can run multiple times - test_migration_skips_if_already_updated: Verifies no-op on new databases **Verification:** 1. All 254 tests pass including the new migration tests 2. Tested migration on copy of production database (644 issues preserved) 3. Deployed to trckr.roboalch.com via ./scripts/deploy.sh 4. Server logs confirm migration ran successfully: ``` 2025-12-17 05:56:46 [INFO] server.database - Migrating issues table: updating status CHECK constraint 2025-12-17 05:56:46 [INFO] server.database - Successfully migrated issues table status constraint ``` **Commit:** 2e503b1 on branch TRCKR-390, merged to master (6e72995)

## QA FAILED See QA report document: f3d4dc78-8ea3-4066-bc56-77249c6eb904 **Critical Issue Found:** The fix (commit dfcba39) is incomplete. While the Pydantic model was updated to include 'backlog' and 'cancelled' statuses, the **SQLite database CHECK constraint was not migrated**. **Error on save:** ``` sqlite3.IntegrityError: CHECK constraint failed: status IN ('triage', 'todo', 'in-progress', 'blocked', 'in-review', 'done', 'archived') ``` **Required to complete the fix:** 1. Database migration to update the CHECK constraint in the issues table 2. The constraint must be updated to include 'backlog' and 'cancelled' 3. Production database on trckr.roboalch.com also needs migration Returning to todo for database migration work.

## Fix Applied **Problem Found:** The frontend templates (issue_detail.html, issue_form.html, base.html, etc.) include 'backlog' and 'cancelled' as valid status options in the issue status dropdown. However, the backend Pydantic model at server/models.py:52 was defined with a Literal type that only accepted: triage, todo, in-progress, blocked, in-review, done, archived. This caused API validation errors when users selected 'cancelled' or 'backlog' from the dropdown. **Change Made:** Modified server/models.py:52 to add 'backlog' and 'cancelled' to the status Literal type. Before: Literal["triage", "todo", "in-progress", "blocked", "in-review", "done", "archived"] After: Literal["triage", "backlog", "todo", "in-progress", "blocked", "in-review", "done", "cancelled", "archived"] **Verification:** - All 23 issue-related server tests pass - All 10 TestIssues tests pass - The Pydantic model now correctly validates 'backlog' and 'cancelled' status values **Commit:** dfcba39 on branch TRCKR-390

## Bug Triage Complete **Reproduction:** CONFIRMED **Summary:** Frontend-backend schema mismatch. The issue detail modal includes 'cancelled' as a status option (line 31 of issue_detail.html), but the backend Pydantic validation model only accepts: triage, todo, in-progress, blocked, in-review, done, archived. When users select 'cancelled', the backend rejects the request with a validation error. **Root Cause:** /Users/joe/gitea/trckr/server/templates/modals/issue_detail.html includes cancelled status option, but /Users/joe/gitea/trckr/server/models.py:52 does not include it in the allowed Literal values. **TDD Approach:** 1. Write test that updates issue status to 'cancelled' via API (should fail) 2. Add 'cancelled' to the status Literal in models.py line 52 3. Verify test passes 4. Test edge cases (transitions to/from cancelled, filtering) **Additional Finding:** 'backlog' status also appears in issue_form.html but not in backend validation - same bug. **Related:** This is exactly what TRCKR-346 aims to prevent by consolidating status definitions. See attached triage report document for full details.

Additional report: User also cannot update the status of TRCKR-16 via the web app. This suggests the issue affects multiple tickets, not just TRCKR-66.