https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42513 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |lisette@bywatersolutions.co |ity.org |m Status|NEW |ASSIGNED -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42513 --- Comment #2 from Lisette Scheer <lisette@bywatersolutions.com> --- Created attachment 199058 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199058&action=edit Bug 42513: Stock rotation upgrades to handle cancelled advancements This patch updates the Koha/StockRotationItem.pm to change needs_advancing to be checked before needs_repatriating. It also updates needs_advancing to handle when the last StockrotationAdvance was cancelled so items don't get stuck never moving. To recreate: 1. Turn on StockRotation in the system preferences 2. Navigate to 'Cataloging'->'Stock Rotation' 3. Click the 'New rota` button give it any name and leave it cyclical 4. On the stock rotations table, click the "Manage" button for your new rota and manage stages 5. Create at least 2 stages at different libraries set the days for each stage to 1 6. In the left hand bar, there should be a 'Manage items' option, click on that. 7. Add 39999000011418 (or a barcode of your choice) to the rota 8. Click 'Stock rotation' in the breadcrumbs 9. on the stock rotation table, activate your rota with the "Activate" button 10. on the stock rotation table, click the manage button, then manage items 11. click 'Move to next stage' 12. Run the following report: select * from branchtransfers You should have 1 transfer with the reason StockrotationAdvance 13. Search the catalog for 39999000011418, edit the item 14. Mark the item as lost 15. Repeat step 12, there should now be a cancellation 16. Remove the lost status 17. Repeat steps 10-12 There should now be one with a cancellation and one without a cancellation 18. Change your library to the library that matches the 'To branch' for your active transfer. 19. Check the item in. 20. Repeat steps 10-12 There should now be a 'date_arrived' on the most recent transfer. 21. Directly edit your database ktd --shell koha-mysql kohadev UPDATE branchtransfers SET date_arrived="date" where branchtransfer_id="yourbranchtransfer_id"; *date arrived should be your date but change the day back in time a day or 2 *branchtransfer_id is the id of the most recent transfer, which should be 2 22. Run your report Observe that the date is updated 23. in your ktd, run this script: perl misc/cronjobs/stockrotation.pl -x (if you're still in the database, first type 'exit' and hit enter) This should show you the results of your item. It should have "status: advancement" This will execute the change. 23. Repeat steps 13-16 24. Repeat steps 21-22 25. in your ktd, run this script (leave the -x off the end) perl misc/cronjobs/stockrotation.pl 26. The status will come up and say 'repatriation' instead of 'advancement' To test the patch: 27. Apply the patch 28. restart_all 29. Repeat steps 10-25 It should now say 'advancement' -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42513 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |martin.renvoize@openfifth.c |y.org |o.uk -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42513 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|lisette@bywatersolutions.co |martin.renvoize@openfifth.c |m |o.uk QA Contact|martin.renvoize@openfifth.c |lisette@bywatersolutions.co |o.uk |m -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42513 --- Comment #3 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203473 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203473&action=edit Bug 42513: Stock rotation upgrades to handle cancelled advancements If a 'StockrotationAdvance' branchtransfer for an item is cancelled (e.g. because the item was marked lost) before it ever arrives, that transfer never receives a 'datearrived'. Koha::StockRotationItem->needs_advancing only ever looked at 'StockrotationAdvance' transfers, and dt_from_string() falls back to "now" when passed an undef value, so the advancement clock was effectively reset to zero every time the stockrotation cron ran. The item would get repatriated back to its stage's branch, but would then sit there forever, never advancing, unless manually advanced. Koha::StockRotationItem->needs_advancing now measures elapsed time from a stable arrival date for the item's *current* stage: normally that's simply the 'StockrotationAdvance' transfer's arrival, exactly as before. Only when that specific advance was cancelled before arriving do we fall back to the first transfer - of any reason, not just 'StockrotationRepatriation' - that subsequently, and successfully, brought the item back to the stage's branch. Two things about that fallback matter: * It has to be the *first* such recovery, not the most recent one: an item can drift off again later (e.g. checked out and returned to the wrong branch) and get transferred back a second time, and that must not keep pushing the advancement clock forward, or the item would never accumulate enough time at the stage to advance as long as this kept happening. * It doesn't have to be a 'StockrotationRepatriation' transfer at all - any transfer reason that actually lands the item back at the stage branch counts (e.g. a plain 'Manual' transfer requested by staff). There's a further wrinkle: if the item is found and simply checked in at its own homebranch (which C4::Circulation::AddReturn already treats as needing no transfer at all - see the 'homebranch' return-branch policy), there will be *no* branchtransfers row recording that arrival. In that case we know an advance was attempted (even though cancelled) and can see via needs_repatriating that the item is genuinely home, so we treat it the same as a fresh arrival rather than leaving it permanently stuck warning about missing history. This needed no changes to needs_repatriating, repatriate, or investigate()'s priority order - once the item is genuinely back at its stage's branch, the existing repatriation/advancement machinery already works correctly; the bug was purely in how needs_advancing measured elapsed time. Rewritten from Lisette Scheer's original patch to fix the root cause directly (the stale/cancelled transfer date lookup) rather than layering extra cancellation-handling branches on top of needs_advancing, repatriate and investigate. Test plan: 1. Apply the patch. 2. prove t/db_dependent/StockRotationItems.t => All tests pass, including the new subtest covering: a cancelled advance recovered with no transfer trail at all (advances rather than staying stuck), a cancelled advance not yet recovered (defers to needs_repatriating), recovery via a non-repatriation transfer reason (still anchors the clock), and a second, later recovery (does not roll the clock forward again). 3. To reproduce the original bug manually: a. Turn on the StockRotation system preference. b. Create a cyclical rota with 2+ stages at different libraries, each with a duration of 1 day. c. Add an item to the rota and activate it. d. Move the item to its next stage (creates a 'StockrotationAdvance' transfer). e. Mark the item lost (cancels the in-progress transfer), then remove the lost status again. f. Check the item in at the destination library, so it repatriates (creates and completes a 'StockrotationRepatriation' transfer). g. Run: perl misc/cronjobs/stockrotation.pl -x Before this patch: the item never reports 'advancement' again, no matter how much time passes - it is stuck reporting 'not-ready'. After this patch: once the stage's duration has elapsed since the repatriation's arrival, the item correctly reports 'advancement' and moves to the next stage. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42513 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |28527 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 [Bug 28527] Transfers that are cancelled whilst in transit should still appear as 'in transit' until they are received -- You are receiving this mail because: You are watching all bug changes.