https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43602 --- Comment #3 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 206597 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206597&action=edit Bug 43602: Add POST /api/v1/article_requests and public patron_add Adds staff and public creation endpoints for article requests, backed by Koha::ArticleRequest->new_from_api($body)->request (the existing Koha::ArticleRequest workflow method, unchanged). add() and patron_add() validate patron_id/biblio_id against the database before attempting the write, following the pattern already used in Koha::REST::V1::Holds, rather than relying on DBIx::Class to raise (and suppressing its warning) on the resulting FK constraint violation - a suppressed warning is easy to lose track of and gives a worse error to the API client. A shared _handle_write_exception($c, $exception) helper maps the remaining Koha::Exceptions (article request limit reached, unsupported format, FK constraint) to the matching HTTP status and error_code, so add() and patron_add() do not duplicate that mapping. Both actions call ->discard_changes on the created object before serializing the response, so DB-computed columns such as updated_on (ON UPDATE current_timestamp()) are reflected accurately rather than echoing back the client's request values. patron_add is the public counterpart, reachable only via $c->auth->public and always overwriting patron_id from the URL's patron_id rather than trusting the request body, so a patron can only ever create a request for themselves. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.