https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43602
--- Comment #1 from Martin Renvoize (ashimema) <[email protected]> --- 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. _______________________________________________ Koha-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected] website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
