Summary: | Item not transferred correctly when there is a pending hold | ||
---|---|---|---|
Product: | Koha | Reporter: | Andrew Fuerste-Henry <andrew> |
Component: | Circulation | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | normal | ||
Priority: | P5 - low | CC: | anneli.osterman, anni.maki-mantila, blawlor, bowens, clackman, emmi.takkinen, gmcharlt, katariina.pohto, kyle, m.de.rooy |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30581 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37650 |
||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: |
Description
Andrew Fuerste-Henry
2024-05-02 16:36:15 UTC
Not sure if this is the same problem but some items at our branch A with a hold for pickup at branch B are not transferred when checking them in at A and clicking Confirm hold and transfer. Note that the hold is updated to a transit hold (found==T) but no transfer is made. Nothing to be found in the logfiles either. Most items go well. No clue yet which conditions must be met to trigger the issue. (In reply to Marcel de Rooy from comment #1) > Not sure if this is the same problem but some items at our branch A with a > hold for pickup at branch B are not transferred when checking them in at A > and clicking Confirm hold and transfer. > Note that the hold is updated to a transit hold (found==T) but no transfer > is made. Nothing to be found in the logfiles either. > > Most items go well. No clue yet which conditions must be met to trigger the > issue. This is in 22.11 btw Not so sure if I could reproduce my issue on master btw. Master added several actions like cud-checkin and cud-affect-reserve in the CSRF changes, which seem to impact the flow here? (In reply to Marcel de Rooy from comment #1) > Not sure if this is the same problem but some items at our branch A with a > hold for pickup at branch B are not transferred when checking them in at A > and clicking Confirm hold and transfer. > Note that the hold is updated to a transit hold (found==T) but no transfer > is made. Nothing to be found in the logfiles either. > > Most items go well. No clue yet which conditions must be met to trigger the > issue. Found this issue. It is a separate bug on itself. See bug 37650 This would be nice to get fixed. It is good that the user is alarmed about existing holds, but user should be able to either transfer the item to the indicated transfer-target or decide not to make the transfer at all. *** Bug 40056 has been marked as a duplicate of this bug. *** (In reply to Andrew Fuerste-Henry from comment #0) > Koha is doing some dumb stuff when one attempts to transfer an item that > could fill a pending hold. To recreate: > > 1 - be logged in at Branch A > 2 - have a bib with 1 holdable item at Branch A > 3 - place a hold for pickup at Branch B > 4 - confirm hold shows on Holds to Pull and Holds Queue > 5 - go to Circulation > Transfers and attempt to send your item to Branch C > 6 - Koha gives you three options. Pick the first one: "Transfer to Branch > B." This is the hold pickup branch, not the branch you selected for your > transfer > 7 - Koha tells you it has transferred the item to Branch C (the branch you > did select for your transfer) > 8 - go to detail.pl for your title, confirm the holdings table says "there > is an item level hold" on your item > 9 - click to the Holds tab for your title, confirm the hold claims to be in > transit > 10 - query the branchtransfers table, confirm no transfer was created > 11 - query reserves and confirm your hold has found=T, itemnumber=[your > item], and item_level_hold=0 > 12 - Back on the title, attempt to revert transit status, confirm the Revert > button doesn't do anything > > > At step 6, Koha should offer to transfer to the indicated transfer-target, > rather than the hold pickup branch. Then it should actually generate the > transfer and should not insert the itemnumber into the reserves table or > update reserves.found. I'm able to reproduce this expect step 12: >12 - Back on the title, attempt to revert transit status, confirm the Revert button doesn't do anything Did you mean "Revert transit status" button in holds table or am I missing something here? |