https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43894 --- Comment #2 from David Nind <david@davidnind.com> --- Created attachment 208908 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=208908&action=edit Bug 43894: Store the new notforloan status with the checkout in AddIssue AddIssue stored the item, which enqueues the reindex of the record, and then applied UpdateNotForLoanStatusOnCheckout with a second store using skip_record_index. If the indexing daemon processed the job between the two stores, the record was indexed with the old notforloan value and nothing reindexed it again. This patch applies the UpdateNotForLoanStatusOnCheckout rule to the item object before the store, so a single store writes onloan and notforloan together and the record is reindexed with the new status. Nothing between the two stores read notforloan. The holds queue is still updated at the end of AddIssue when RealTimeHoldsQueue is enabled. The race cannot be reproduced reliably by hand, the new test checks that the item already has the new notforloan value when the reindex is enqueued. Steps to follow: 1. Set AllowNotForLoanOverride to "Allow" and UpdateNotForLoanStatusOnCheckout to: -1: 0 2. Edit an item that is not checked out and set "Not for loan" to "Ordered". Search for its record: the item is shown as "Ordered". 3. Apply the patch and restart_all (or restart Plack). 4. Check the item out, confirming the "not for loan" warning. 5. The item is no longer "Ordered" (its not for loan value is now 0), and the search results show it as checked out. 6. Check the item in and restore the two preferences. 7. prove t/db_dependent/Circulation/issue.t Without the patch, the new subtest fails: the item still has the old notforloan value (-1) when the record reindex is enqueued. Signed-off-by: Adolfo Rodríguez <adolfo.rodriguez@xercode.es> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.