Você já tentou passar o nome de usuário também como um parâmetro de consulta? (ou seja, adicionando ?username=<username> à URL)
Parece que não estávamos sendo totalmente consistentes com a forma como permitíamos que a API recuasse para o nome de usuário Api-Username quando nenhum parâmetro de consulta username era fornecido.
Isso deve ser corrigido com
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