https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43602 --- Comment #1 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Suggested API shape, based on comparing this to two other request-workflow modules already in the codebase (Tickets/catalog concerns, and the newer ISO18626 supplying-agency API): Design precedent ----------------- Two existing patterns were compared: 1. Tickets (Koha::REST::V1::Tickets, api/v1/swagger/paths/tickets.yaml): full CRUD resource. Status/assignee changes are just fields on the same object, applied via a generic PUT /tickets/{id}; side effects (notices, resolver_id/resolved_date, a Ticket::Update audit row) are triggered by inspecting which columns changed (get_dirty_columns), not by one bespoke endpoint per transition. 2. ISO18626 supplying-agency requests (Koha::REST::V1::ILL::ISO18626::Requests, api/v1/swagger/paths/ill_iso18626_requests.yaml): GET list/single plus PUT .../{id} (the "edit" action), which accepts a JSON body containing "status" (plus protocol-specific fields) and passes it straight to $request->progress_request('supplyingAgency', $body) to drive the underlying state machine and emit the correct outbound message. This is the newest ILL-adjacent code in the module and is entirely Vue + REST driven (SupplyingResource.vue / RequestingAgencyResource.vue), with no legacy op=cud-* CGI involved at all. Both converge on: one resource, one generic update verb, status supplied in the body, business logic and side effects staying in the object layer rather than in bespoke controller actions per transition. This is the opposite of the current article request and legacy ILL request design, where each transition is its own Perl method invoked via a distinct op= value on a cookie-authenticated CGI/svc script. Suggested shape for article requests ------------------------------------- Add a new swagger definition "article_request" (Koha::ArticleRequest currently has no to_api_mapping/public_read_list at all, so this is new plumbing, not just new routes). Fields: article_request_id, patron_id, biblio_id, item_id, library_id (branchcode), title, author, volume, issue, date, pages, chapters, patron_notes, toc_request, status (read-only), format, urls, cancellation_reason, notes, debit_id (read-only), created_on (read-only), updated_on (read-only), with optional x-koha-embed for biblio/item/patron/library. Endpoints: GET /api/v1/article_requests list (staff queue; filter by status/branchcode via -q-/embed, replacing the three canned queries requested()/pending()/processing() the .pl script currently builds by hand) GET /api/v1/article_requests/{article_request_id} get single POST /api/v1/article_requests create on a patron's behalf (staff), wraps Koha::ArticleRequest->request PUT /api/v1/article_requests/{article_request_id} generic update: body may set status (PENDING|PROCESSING|COMPLETED|CANCELED), urls, library_id. Controller maps a changed "status" to the matching existing object method (set_pending/process/complete/cancel) rather than writing the column directly, so fee charging/refunding and notify() stay centralised in Koha::ArticleRequest exactly as they are today. DELETE /api/v1/article_requests/{article_request_id} unchanged (existing cancel action, already released - keep for backward compatibility; PUT status=CANCELED becomes an equivalent path going forward) POST /api/public/patrons/{patron_id}/article_requests patron self-service create (OPAC), wraps the same ->request call used by opac-request-article.pl. Currently missing entirely - only the public cancel route exists. DELETE /api/public/patrons/{patron_id}/article_requests/{article_request_id} unchanged (existing patron_cancel action) Permissions unchanged from what's already enforced: circulate/circulate_remaining_permissions for staff routes (matches the existing DELETE route and the svc/article_request auth check), patron auth for the public routes (matches the existing patron_cancel route). Once this exists, koha-tmpl/intranet-tmpl/prog/js/fetch/article-request-api-client.js and the JS in circ/article-requests.tt / circ/request-article.tt can be moved off svc/article_request onto the new endpoints, and that legacy script can eventually be retired. That migration/retirement would be a sensible follow-up rather than part of this bug's initial scope. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

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.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43602 --- Comment #5 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 206599 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206599&action=edit Bug 43602: Migrate staff and OPAC UI off svc/article_request Rewrites koha-tmpl/intranet-tmpl/prog/js/fetch/article-request-api-client.js to wrap the new REST endpoints (GET/POST/PATCH under /api/v1/article_requests and /api/v1/public/patrons/{patron_id}/article_requests) instead of posting op=cud-* actions to the legacy cookie-authenticated svc/article_request CGI script, and updates the staff article-requests queue (circ/article-requests.tt), the staff request-article form (circ/request-article.tt) and the OPAC patron account page (opac-user.tt) to call the client's new methods. The previous DELETE-based cancel routes are already gone as of the previous commit, so this finishes moving every caller in this codebase onto the REST client. Removing svc/article_request itself is left as a separate follow-up rather than folded into this bug, to keep this series focused on the new API surface. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43602 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl -- You are receiving this mail because: You are watching all bug changes.