## QA PASSED (Re-test) See QA report document: da036398-93d4-4fd1-a2c5-5f5aadb76219 **All tests passed:** - Attachments page loads with 10 uploaded images visible - Search works correctly (no 500 error) - tested "test", "blue", "multi" - "Uploads" filter shows virtual attachments correctly - Download links work - images display in new tab - No console errors The search crash fix is working. Virtual attachments feature verified complete.

## Fix Applied **Problem Found:** Search on attachments page crashed with `AttributeError: 'NoneType' object has no attribute 'lower'` when virtual attachments (uploaded images) were present. **Root Cause:** Virtual attachments in `_get_uploads_as_virtual_attachments()` set `title` and `subtitle` to `None` explicitly (line 2984-2985). The search code used `.get("title", "").lower()` which returns `None` when the key exists with `None` value, causing `.lower()` to fail. **Changes Made:** 1. `server/routes/web.py:2984-2985` - Changed `title: None` and `subtitle: None` to `title: ""` and `subtitle: ""` with comments explaining why 2. `server/routes/web.py:3047-3049` - Made search code robust by using `(a.get("title") or "").lower()` pattern instead of `a.get("title", "").lower()` **Verification:** - Server tests: 109 passed - E2E tests: 30 passed The fix applies both a defensive fix to the source data (empty strings instead of None) and makes the search code robust against any future None values.

## QA FAILED See QA report document: 312ee28e-a1ed-4b0c-ab23-282e6db76c48 **What Works:** - Virtual attachments appear on attachments page (10 files visible) - "Uploads" filter exists and works correctly - Download links work - images display properly - Type/Owner columns show correct values - File size and dates are correct **Issues Found:** 1. **CRITICAL: Search crashes with 500 error** - Enter text in search box, press Enter -> Server returns 500 - Error: `AttributeError: 'NoneType' object has no attribute 'lower'` - Location: `server/routes/web.py:3047-3049` - Root cause: Virtual attachments set `title`, `subtitle` to `None` explicitly (line 2984). Search code uses `.get("title", "").lower()` which returns `None` when key exists with `None` value. - Fix: Use `(a.get("title") or "").lower()` or set fields to `""` instead of `None` Returning to todo for fixes.

## Fix Implemented **Problem**: Images uploaded via drag-and-drop into issue descriptions were saved to `data/uploads/` but did not appear on the attachments page because they did not have database records. **Root Cause**: The `/web/upload-image` endpoint saves files to the `uploads/` directory without creating attachment records in the database. This was by design - at upload time, we don't know which issue the image will be attached to (the issue might not exist yet). **Solution Implemented**: Instead of modifying the upload workflow, I added a "virtual attachments" feature: 1. **New helper function** `_get_uploads_as_virtual_attachments()` in `server/routes/web.py:2948-3000`: - Scans the `uploads/` directory for files - Creates virtual attachment records with `owner_type="upload"` - Includes file metadata (name, size, mime type, modification date) 2. **Modified attachments list** in `server/routes/web.py:3003-3025`: - Merges virtual uploads with database attachments - Supports filtering by `owner_type=upload` 3. **Updated templates**: - Added "Uploads" filter option to dropdown in `attachments.html` - Added "upload" to header filter in `attachments_table.html` - Virtual attachments show "Inline image" in Owner column - Download links point to `/web/uploads/filename` instead of attachment ID **Verification**: - Server tests pass (109 tests) - E2E tests pass (30 tests) **How Users Will See This**: - Navigate to Attachments page - Uploaded images now appear with type "upload" and owner "Inline image" - Filter by "Uploads" to see only inline images - Click filename to view/download the image

## Bug Triage Complete **Reproduction:** CONFIRMED **Summary:** The `upload_image` endpoint (POST /web/upload-image) saves files to `data/uploads/` but does NOT create attachment records in the database. This is by design - two separate systems exist: 1. **Image Upload** - For inline markdown images (no DB records) 2. **Attachments** - For formal file attachments (with DB records) **Root Cause:** Architectural - the image upload endpoint doesn't know which issue/project to attach to at upload time (issue doesn't exist yet). **Test Gap:** Existing tests verify file upload works but don't check for database records. **TDD Approach:** - Option A: Create orphan attachment records, link when issue is saved - Option B: Add separate "Uploads" view to browse uploaded files - Option C: Document as designed, clarify UI terminology See attached triage report for full analysis. **Recommendation:** This requires a product decision on whether inline images should be formal attachments or remain separate.