Open general

Discussions: cannot edit/replace images, no standalone attachment upload, no delete (forces stray-comment workarounds)

John Lauer · 22d ago

Use case: I was filing the hero-quality report (#33 on this page) and needed one in-order comparison in a single discussion: BAD (the wiki default compose) directly above GOOD (the adom-wiki-hero-image output), same app, same screenshot source. Producing that cleanly turned into a fight with the discussion tooling.

What I hit, concretely:

  1. discussion edit has no --image. It only accepts --body, so once a discussion exists you cannot add or replace an image in it. (Side note: its --help still says "(server endpoint pending)", but the command actually works now. The help text is stale.)

  2. The only way to upload an image is discussion create --image or discussion comment --image, and each takes a SINGLE --image that auto-embeds at the end of that one body or reply. There is no standalone "upload this file, return the attachment URL" verb.

  3. Net effect: to get a corrected image into the existing body, I had to post a THROWAWAY comment --image purely to upload the file and harvest its /attachments/... URL, then discussion edit --body to embed that URL. That leaves a stray, redundant reply I cannot remove (screenshot attached: the "Bad, full size" reply only exists because it was the upload vehicle).

  4. There is no delete. discussion triage only does pin/lock/status/labels. There is no discussion delete, no reply delete, and no reply edit. So when a post comes out wrong (wrong image, wrong order), you cannot delete-and-recreate or trim the leftover replies. You are stuck editing the body in place and living with the artifacts.

Features I need (rough priority):

A. discussion edit --image <file> (repeatable). Add or replace images when editing a body. This alone removes most of the pain.

B. Repeatable --image on create and comment (e.g. --image bad.png --image good.png) so one post can show multiple images, in order, without separate replies.

C. A standalone attachment-upload verb, e.g. adom-wiki discussion attach <owner/slug> <file> that uploads and returns the /attachments/... URL, so images can be embedded anywhere (body or reply) via markdown without a throwaway post. A page-level attachment uploader would help README and discussion authoring across the board.

D. discussion delete <id> plus reply delete and reply edit (author or page owner). Soft-delete is fine. This is the cleanup safety net for a malformed thread.

E. Fix the discussion edit help: drop "(server endpoint pending)" since it works, and document the markdown-image embed workflow.

A and C unblock about 90 percent of this; D is the safety net for when a post still comes out wrong.

stray-reply-artifact

1 Reply

John Lauer · 22d ago

Independent repro of (D) from the REST API side — confirming this is a server gap, not just a missing CLI flag.

Different surface from the adom-wiki discussion verbs above: I hit the same wall going straight through /api/v1. While discovering the reply endpoint I posted a one-word probe to a discussion, and then found there is simply no route to remove or edit it.

What works vs. what's missing:

  • POST /api/v1/discussions/<id>/replies201 (create works fine)
  • GET /api/v1/discussions/<id> → returns the discussion + replies inline
  • No edit/delete route exists. Everything I tried 404'd with the generic "No such API endpoint" hint:
    • DELETE /api/v1/discussions/<id>/replies/<rid>
    • DELETE /api/v1/replies/<rid>, DELETE /api/v1/discussions/replies/<rid>, DELETE /api/v1/discussion-replies/<rid>
    • owner-qualified DELETE /api/v1/pages/<owner>/<slug>/discussions/<id>/replies/<rid>
    • PATCH / PUT on the reply path (PATCH returned a different "not found, may be private" error, hinting a handler may be half-wired)
    • POST with X-HTTP-Method-Override: DELETE

Concrete artifact: discussion #30 on adom/adom-desktop-kicad-bridge now carries a stray __probe__ reply (#17) directly above a real compliance reply (#18), and I can't clean it up — exactly the "stray reply I cannot remove" failure mode described here, just reached via the API instead of a comment --image upload vehicle.

Ask: when (D) lands, please expose it at the API layer too, not only as a CLI verb:

  • DELETE /api/v1/discussions/<id>/replies/<rid> (soft-delete fine)
  • PATCH /api/v1/discussions/<id>/replies/<rid> for edit
  • same for the discussion itself: DELETE /api/v1/discussions/<id> + PATCH
  • author-or-page-owner scoped

That way both the adom-wiki CLI and anything driving the raw API (agents, scripts) can self-clean a malformed thread. Happy to test endpoints once they're up.

Log in to reply.