https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43879 --- Comment #1 from Adolfo Rodríguez Taboada <adolfo.rodriguez@xercode.es> --- Created attachment 208639 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=208639&action=edit Bug 43879: Reindex the record when a withdrawn item blocks the return If the item is not checked out but has items.onloan set, AddReturn clears onloan with skip_record_index, as the record is reindexed at the end of the function. When the item is withdrawn and BlockReturnOfWithdrawnItems blocks the return, AddReturn returned early, before that reindex, so the search results kept showing the item as checked out. This patch reindexes the record before that early return when onloan has been cleared, the same way the Wrongbranch early return already does. When RecordLocalUseOnReturn is enabled, the localuse store already reindexes the record, so it is not reindexed a second time. Steps to follow: 1. Make sure the search index is updated automatically (koha-es-indexer running, or the Zebra daemon). 2. Enable BlockReturnOfWithdrawnItems and disable RecordLocalUseOnReturn. 3. Take an item that is not checked out, set it as withdrawn and set items.onloan, for example: UPDATE items SET withdrawn = 1, onloan = CURDATE() WHERE itemnumber = X; and reindex its record: misc/search_tools/rebuild_elasticsearch.pl -b --bnumber <biblionumber> 4. Search the catalog: the item is shown as checked out. 5. Check the item in: the return is blocked (item withdrawn). items.onloan is now NULL, but the search results still show the item as checked out. 6. Apply the patch and restart Plack if running under it. 7. Repeat steps 3 to 5. Now the search results no longer show the item as checked out, only as withdrawn. 8. Enable RecordLocalUseOnReturn and repeat steps 3 to 5: local use is recorded and the record is reindexed (only once). 9. prove t/db_dependent/Circulation.t Signed-off-by: Adolfo Rodríguez <adolfo.rodriguez@xercode.es> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.