QuickCapture drop-zone implies image attach but only inserts placeholder text #110

New issue

Closed

opened 2026-07-15 19:52:55 +00:00 by claude-bot · 1 comment

claude-bot commented

2026-07-15 19:52:55 +00:00

Contributor

Severity: Medium · Confidence: High · Effort: S · Category: ui

Evidence

app/src/components/layout/QuickCapture.tsx:208-216 - handleDrop appends the literal string [image: filename] (comment at :214 admits no upload happens); :254-258 - the drop zone visibly invites "Drop image to attach".

Problem
The UI presents a highlighted "Drop image to attach" affordance, but nothing is uploaded - the user gets bracketed placeholder text and must re-attach the image manually from the entry later.

Impact
Misleading affordance; users will reasonably believe the image was attached and lose track of it.

Fix
Either wire the drop to a real staged upload after entry creation, or remove the drop-zone affordance until implemented.

Acceptance criteria

The drop zone either actually attaches the image or no longer advertises that it does.

Filed from the 2026-07-15 codebase audit. Full report: docs/.internal/report-2026-07-15.md (gitignored).

**Severity:** Medium · **Confidence:** High · **Effort:** S · Category: ui **Evidence** - `app/src/components/layout/QuickCapture.tsx:208-216` - `handleDrop` appends the literal string `[image: filename]` (comment at :214 admits no upload happens); `:254-258` - the drop zone visibly invites "Drop image to attach". **Problem** The UI presents a highlighted "Drop image to attach" affordance, but nothing is uploaded - the user gets bracketed placeholder text and must re-attach the image manually from the entry later. **Impact** Misleading affordance; users will reasonably believe the image was attached and lose track of it. **Fix** Either wire the drop to a real staged upload after entry creation, or remove the drop-zone affordance until implemented. **Acceptance criteria** - [ ] The drop zone either actually attaches the image or no longer advertises that it does. --- _Filed from the 2026-07-15 codebase audit. Full report: `docs/.internal/report-2026-07-15.md` (gitignored)._

claude-bot added this to the v7.3.0 - UI, mobile & accessibility milestone

2026-07-15 19:52:55 +00:00

claude-bot added the

bug

label

2026-07-15 19:52:55 +00:00

rbrooks referenced this issue from a commit

2026-07-17 22:48:57 +00:00

feat(v7.3.0): UI, mobile & accessibility milestone

claude-bot commented

2026-07-17 23:14:16 +00:00

Author

Contributor

QuickCapture image drop now really uploads the image (mirrors the voice-note path: ensure the entry exists, then POST /api/media/:entryId), with an Attaching…/Attached indicator; offline drops explain to attach from the entry page. No more misleading [image: filename] placeholder text.

Shipped in 59e4fdd (test fix 6561f9a), part of the v7.3.0 milestone. Verified on dev (v7.2.1-3-g6561f9a): app suite 65/65 and api suite 268/268 green on the dev server; the one CI red was the known runner flake (iac#159), not this change.

QuickCapture image drop now **really uploads** the image (mirrors the voice-note path: ensure the entry exists, then `POST /api/media/:entryId`), with an Attaching…/Attached indicator; offline drops explain to attach from the entry page. No more misleading `[image: filename]` placeholder text. Shipped in `59e4fdd` (test fix `6561f9a`), part of the v7.3.0 milestone. Verified on dev (`v7.2.1-3-g6561f9a`): app suite 65/65 and api suite 268/268 green on the dev server; the one CI red was the known runner flake (iac#159), not this change.

claude-bot closed this issue

2026-07-17 23:14:17 +00:00