https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43876
--- Comment #4 from David Nind <[email protected]> --- Created attachment 208910 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=208910&action=edit Bug 43876: Use Koha::Item->delete when cancelling a receipt When the basket creates items on receiving, CancelReceipt deleted those items with a raw SQL DELETE in _cancel_items_receipt. This bypassed Koha::Item->delete, so: - no copy of the item was kept in deleteditems - the bibliographic record was not reindexed, so the deleted items were still shown in the search results - nothing was written to the cataloguing log - the after_item_action plugin hook was not called - the real-time holds queue was not updated - an item group left empty was not deleted This patch deletes each item with move_to_deleted and Koha::Item->delete, and removes the aqorders_items row explicitly (that table has no foreign key on items, so it is not cleaned up by the item deletion). The record is reindexed, and the holds queue updated, once after all the items have been deleted. It also adds the missing POD for _cancel_items_receipt. As before, the items are deleted without checking whether they can be safely deleted (checkouts, holds...): only the deletion mechanism changes. Steps to follow: 1. Make sure the search index is updated automatically (koha-es-indexer running, or the Zebra daemon), and enable CataloguingLog. 2. Create a basket with "Create items when: receiving an order", add an order with quantity 2, close the basket and receive the order. Two items are created and are shown in the catalog search results. 3. Cancel the receipt. The items are gone from the record details page, but: - they are not in deleteditems: SELECT * FROM deleteditems WHERE biblionumber = <biblionumber>; - there is no DELETE entry for them in the cataloguing log (Tools > Log viewer > Cataloging) - the catalog search results still show the items 4. Apply the patch and restart Plack if running under it. 5. Repeat steps 2 and 3 with a new order. Now the items are moved to deleteditems, the cataloguing log shows a DELETE entry for each item, and the search results no longer show them. 6. Receive only 1 item of an order with quantity 2 (the order is split) and cancel that receipt: the item is moved to deleteditems and the original order is pending again with quantity 2. 7. With a basket that creates items on ordering, receive an order and cancel the receipt: the item is not deleted and is linked again to the pending order (no change in behaviour). 8. prove t/db_dependent/Acquisition/CancelReceipt.t Signed-off-by: Adolfo RodrÃguez <[email protected]> Co-Authored-By: Claude Opus 5.5 <[email protected]> Signed-off-by: David Nind <[email protected]> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. _______________________________________________ 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/
