https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42383 --- Comment #55 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 209606 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=209606&action=edit Bug 42383: (QA follow-up) Update the holds queue on check-in This patch makes POST /checkins enqueue a BatchUpdateBiblioHoldsQueue background job for the item's record when RealTimeHoldsQueue is enabled, as the legacy circ/returns.pl did. AddReturn passes skip_holds_queue internally, so without this the real-time holds queue was never refreshed after a check-in from the new page. The job is enqueued when: - the item was returned (legacy did it after AddReturn), or - a hold was found for the item. The legacy page enqueued the job when the staff chose 'Ignore' on the hold modal. The new page dismisses the hold modal client-side without calling the API, so the update is done at check-in time instead. Cancelling the hold found already updates the queue, as Koha::Hold->cancel enqueues the job itself. Confirming it did not update the queue in legacy either. It addresses point 5 of the QA comment. Test plan: 1. Enable RealTimeHoldsQueue 2. Check out an item and go to Administration > Jobs, note the number of 'Update holds queue for biblios' jobs 3. Check the item in on the check-in page 4. Reload the jobs page => FAIL: No new 'Update holds queue for biblios' job 5. Apply this patch and restart plack: $ ktd --shell k$ koha-plack --restart kohadev 6. Repeat 2 to 4 => SUCCESS: A new job is listed for the item's record 7. Run: k$ prove t/db_dependent/api/v1/checkins.t => SUCCESS: Tests pass! 8. Sign off :-D Assisted-by: Opus 5.5 (Anthropic) -- You are receiving this mail because: You are watching all bug changes.