Closed feature request

Issues: upload any file type from the UI (not just images)

Drew Owens · 2mo ago ·closed by Colby Knox

The ask

Let people attach files of any type to an issue from the web UI: a picker button and drag-drop onto the composer, on both new issues and replies.

Images already work well after #83 and #92, but images are only half of what a bug report carries. The attachments that actually reproduce a problem are things like:

  • a log file or console dump
  • a JSON payload or config that triggers the bug
  • a .kicad_sym / .kicad_mod / GLB / STEP that renders wrong
  • a CSV export with the bad rows
  • a zip of a minimal repro

Today the workaround is pushing the file to some page repo and linking it, which pollutes a real page's history with debris, or pasting file contents inline as text, which destroys formatting and truncates.

Shape

  • UI: attach button plus drag-drop on the issue composer and reply composer. Uploaded file becomes a link chip in the body, images keep their inline preview behavior.
  • CLI parity: generalize the existing repeatable --image flag with a --file flag on issue create / comment / edit, embedding a download link in flag order, same as images embed today.
  • Storage can reuse whatever bucket the image uploads landed in; the only new work is accepting more content types and rendering a file chip instead of an img tag.

Guardrails worth deciding up front

  • a size cap per file and per issue
  • an allowlist or at least an executable blocklist, since these are user uploads served back to teammates
  • content-disposition attachment on download so nothing served executes in the wiki origin

Reported while wanting to attach a log file and a KiCad footprint to an issue and having no good place to put either.

1 Reply

Colby Knox · 2mo ago

Shipped, live on prod. Issues and replies now take file attachments from the web UI, and your guardrails are all in.

What you get

  • Attach button + drag-drop on both composers (new issue and reply), plus paste for images. Uploads embed at the cursor: images as inline previews, files as links the page renders as file chips.
  • Allowed types: the image set as before, plus log, txt, md, json, yaml, yml, toml, ini, csv, tsv, xml, patch, diff, zip, gz, tgz, tar, kicad_sym, kicad_mod, kicad_sch, kicad_pcb, kicad_pro, lbr, glb, gltf, step, stp, stl, obj, pdf, hex, uf2, map. Your log-file-and-footprint case is exactly covered.

The guardrails you asked to decide up front

  • Size caps: 25MB per file, images stay at 10MB. No per-issue aggregate cap for now; attachments are page-scoped and content-addressed (identical bytes dedupe to one object), so the pressure is lower than it looks. Easy to add if it gets abused.
  • Type policy: allowlist, not a blocklist, so the surface stays intentional; no executables, no html/svg.
  • Nothing served can render or execute: every non-image is stored and served as application/octet-stream with Content-Disposition: attachment plus nosniff, and the disposition is stamped into the object metadata at upload, so the R2 public alias and presigned paths download it identically. The bytes are never sniffed into a type; a file named .log full of HTML downloads as a log file. (Verified end to end against the staging bucket before promoting.)

CLI parity

Filed as adom/adom-wiki-cli#21: repeatable --file on issue create/comment/edit, generalizing --image, embedding links in flag order. The endpoint contract (field name, caps, BAD_ATTACHMENT_TYPE with data.allowed) is documented there.

Closing as shipped; reopen if a type you need is missing from the list, that is a one-line addition.

Log in to reply.