Hast du bereits versucht, den Benutzernamen ebenfalls als Abfrageparameter zu übergeben? (d. h. ?username=<username> an die URL anzuhängen)
Es scheint, als wären wir bei der Behandlung des Fallbacks der API auf den Benutzernamen in Api-Username, wenn kein username-Abfrageparameter angegeben wurde, nicht ganz konsistent.
Dies sollte mit folgendem Pull Request behoben sein:
main ← fetch-target-user-helper
opened 10:29AM - 22 Apr 26 UTC
Admin callers using the API to `DELETE /drafts/:id.json` or `DELETE /review/:id.… json` received a `not_found` error when the `username` param was omitted, even though the resource existed and was owned by the API user (`Api-Username`). The destroy actions always called `fetch_user_from_params` on the API path, which raises `Discourse::NotFound` when neither `username` nor `external_id` is provided — forcing callers to redundantly pass `username=<self>` to delete their own resources.
Extract the target-user resolution into a shared `fetch_target_user` helper in `ApplicationController` that mirrors the pattern already used by `topics#set_notifications`: for API requests, an admin can target another user via `username`/`external_id`; otherwise the action operates on `current_user`. This also aligns API capabilities with the UI — non-admin API callers can now manage their own drafts/reviewables, matching what they can already do via the web.
Migrated call sites:
- `DraftsController#destroy` and `#bulk_destroy`
- `ReviewablesController#destroy`
- `TopicsController#set_notifications` (now uses the helper instead of its inline version)
https://meta.discourse.org/t/401220