https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39962 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |19532 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19532 [Bug 19532] Recalls for Koha -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39962 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|19532 |38512 --- Comment #1 from Aleisha Amohia <aleisha@catalyst.net.nz> --- Looks like this was caused by Bug 38512 - item-level recalls display as expected, but biblio-level recalls don't indicate who the return notice was sent to. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19532 [Bug 19532] Recalls for Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38512 [Bug 38512] Item table status column display is wrong when record has recalls -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39962 --- Comment #2 from Aleisha Amohia <aleisha@catalyst.net.nz> --- Created attachment 182807 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=182807&action=edit Bug 39962: Allocate item to bib-level recall when checkout chosen When a biblio-level recall is requested, the checkout with the oldest due date is chosen to have its due date adjusted and sent a return notice. However the chosen checkout item isn't assigned to the recall. This makes it hard for Koha to know which item to show as 'recalled' on the biblio detail page. This patch allocates the checked out item that gets chosen for the recall by oldest due date, to the recall in the database. This patch then checks if the item has an attached recall to display recall information on the biblio detail page, rather than checking for if the UseRecalls system preference is enabled. To test: 1) Enable the UseRecalls system preference and set recalls-related circulation rules. 2) Find a record with at least one item 3) Check out an item in this record to Patron B 4) Log into the OPAC as Patron A and place a biblio-level recall on the record 5) View the record on the staff interface and look at the holdings table 6) The checked out item should now also show a message that it is recalled. 7) Cancel the recall 8) Go back to the OPAC as Patron A and this time place an item-level recall on the checked out item 9) View the record on the staff interface and confirm the recall message shows as expected 10) Confirm all tests pass t/db_dependent/Koha/Item.t , t/db_dependent/Koha/Recalls.t , t/db_dependent/Koha/Plugins/Recall_hooks.t Sponsored-by: Auckland University of Technology -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39962 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39962 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39962 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #182808|0 |1 is obsolete| | --- Comment #5 from David Nind <david@davidnind.com> --- Created attachment 182867 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=182867&action=edit Bug 39962: Allocate checkout item to current recalls 1. Set up a recall before applying both of these patches 2. Apply the first patch and notice that the recall still doesn't show, because it was created before the patch was applied 3. Apply this patch, install database updates and restart services 4. Notice your old recall now shows as requested and was allocated the relevant checkout item Sponsored-by: Auckland University of Technology Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39962 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA CC| |m.de.rooy@rijksmuseum.nl --- Comment #6 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Hi Aleisha, I have Two questions. [1] The title of this report suggests a display problem. But there is an atomic update. Could you explain further? Also we should not use Koha::Objects in those sql scripts, but pure SQL statements. Cant find that coding guideline right now ;) But just git grep on "Koha::" in db_revs. Just finding a few offenders.. [2] You make various small changes in modules but we have no tests.. Could you add them or explain why it is too hard to do so in this case ? Thanks -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39962 Wainui Witika-Park <wainuiwitikapark@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #182866|0 |1 is obsolete| | Attachment #182867|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39962 --- Comment #9 from Wainui Witika-Park <wainuiwitikapark@catalyst.net.nz> --- Created attachment 206497 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206497&action=edit Bug 39962: Allocate checkout item to current recalls 1. Set up a recall before applying both of these patches 2. Apply the first patch and notice that the recall still doesn't show, because it was created before the patch was applied 3. Apply this patch, install database updates and restart services 4. Notice your old recall now shows as requested and was allocated the relevant checkout item Sponsored-by: Auckland University of Technology Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39962 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off Comma delimited| |Auckland University of list of Sponsors| |Technology -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39962 --- Comment #10 from David Nind <david@davidnind.com> --- Created attachment 207013 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207013&action=edit Bug 39962: Allocate item to bib-level recall when checkout chosen When a biblio-level recall is requested, the checkout with the oldest due date is chosen to have its due date adjusted and sent a return notice. However the chosen checkout item isn't assigned to the recall. This makes it hard for Koha to know which item to show as 'recalled' on the biblio detail page. This patch allocates the checked out item that gets chosen for the recall by oldest due date, to the recall in the database. This patch then checks if the item has an attached recall to display recall information on the biblio detail page, rather than checking for if the UseRecalls system preference is enabled. To test: 1) Enable the UseRecalls system preference and set recalls-related circulation rules. 2) Find a record with at least one item 3) Check out an item in this record to Patron B 4) Log into the OPAC as Patron A and place a biblio-level recall on the record 5) View the record on the staff interface and look at the holdings table 6) The checked out item should now also show a message that it is recalled. 7) Cancel the recall 8) Go back to the OPAC as Patron A and this time place an item-level recall on the checked out item 9) View the record on the staff interface and confirm the recall message shows as expected 10) Confirm all tests pass t/db_dependent/Koha/Item.t , t/db_dependent/Koha/Recalls.t , t/db_dependent/Koha/Plugins/Recall_hooks.t Sponsored-by: Auckland University of Technology Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39962 --- Comment #12 from David Nind <david@davidnind.com> --- My testing notes (using KTD). Set up ====== Set circulation and fine rules: - Recalls allowed (total): 5 - Recalls per record (count): 5 - On shelf recalls allowed: if any unavailable - Recall due date interval (day): 5 - Recall overdue fine amount: 5 - Recall pickup period (day): 5 Records used to test: - Programming Perl (262), has one item (39999000011418) - Intermediate Perl (126), has four items Patrons used to test: - Patron A: Mary Burton (change user name and password so you can log in to the OPAC as them) - Patron B: Lisa Charles Before applying any patches - first patch test plan =========================== Steps 4 to 6: Check out Programming Perl to Lisa Charles and place a biblio-level recall by Mary Burton: - Message in holdings table - no mention of recall: Checked out to Lisa Charles (23529000197047): due 10/04/2026 Steps 8 to 9: Messages shown in the holding stable after placing an item-level recall (recall message repeated): Checked out to Lisa Charles (23529000197047): due 10/04/2026 Recalled by Mary Burton (23529000651225) on 09/29/2026 Recalled by Mary Burton (23529000651225) on 09/29/2026 Applying the first patch - with a existing recall in place ======================== As per the second patch, with an item-level recall in place before the patch is applied: - Have an item-level recall in place before apply the first patch - Apply the first patch, restart everything - Repeated message is no longer shown: Checked out to Lisa Charles (23529000197047): due 10/04/2026 Recalled by Mary Burton (23529000651225) on 09/29/2026 - Apply the second patch, update the database (updatedatabase), restart everything - No change to the message As per the second patch, with a biblio-level recall placed: - Reset everything in KTD - Repeat the set up - Place a biblio-level recall - Holdings table shows: Checked out to Lisa Charles (23529000197047): due 10/04/2026 - Apply the first patch, restart_all - No change to the holdings table - Apply the second patch, update the database, restart_all - Holdings table now shows: Checked out to Lisa Charles (23529000197047): due 10/04/2026 Recalled by Mary Burton (23529000651225) on 09/29/2026 Tests ===== prove t/db_dependent/Koha/Item.t t/db_dependent/Koha/Recalls.t t/db_dependent/Koha/Plugins/Recall_hooks.t -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39962 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39962 --- Comment #13 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 207630 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207630&action=edit Bug 39962: Allocate item to bib-level recall when checkout chosen When a biblio-level recall is requested, the checkout with the oldest due date is chosen to have its due date adjusted and sent a return notice. However the chosen checkout item isn't assigned to the recall. This makes it hard for Koha to know which item to show as 'recalled' on the biblio detail page. This patch allocates the checked out item that gets chosen for the recall by oldest due date, to the recall in the database. This patch then checks if the item has an attached recall to display recall information on the biblio detail page, rather than checking for if the UseRecalls system preference is enabled. To test: 1) Enable the UseRecalls system preference and set recalls-related circulation rules. 2) Find a record with at least one item 3) Check out an item in this record to Patron B 4) Log into the OPAC as Patron A and place a biblio-level recall on the record 5) View the record on the staff interface and look at the holdings table 6) The checked out item should now also show a message that it is recalled. 7) Cancel the recall 8) Go back to the OPAC as Patron A and this time place an item-level recall on the checked out item 9) View the record on the staff interface and confirm the recall message shows as expected 10) Confirm all tests pass t/db_dependent/Koha/Item.t , t/db_dependent/Koha/Recalls.t , t/db_dependent/Koha/Plugins/Recall_hooks.t Sponsored-by: Auckland University of Technology Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39962 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pedro.amorim@openfifth.co.u | |k Status|Passed QA |Failed QA --- Comment #15 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Hi all, this is not yet ready for push. Picking up on Marcel's question from comment 6: the bug describes a display problem in the holdings table, but the patches also change circulation logic and add a database update. Marcel's points there were never answered, and they're where the problems are: 1) Which loan gets recalled has changed. When a record-level recall is placed, Koha picks a checked out item to recall and shortens that loan. To decide which items can be recalled, Koha::Recall->checkout checks 'recalls_allowed'. It used to use the logged in library's rule, the patches change it to the pickup library's rule. If those rules differ, a different patron's loan gets shortened. This isn't mentioned in the commit messages, and it seems to be there only so the atomicupdate doesn't crash (there's no logged in library during updatedatabase). To reproduce: 1) Apply the patches, updatedatabase, restart_all 2) Set 'UseRecalls' to 'can be placed through both the OPAC and staff interface' 3) In http://localhost:8081/cgi-bin/koha/admin/smart-rules.pl, on the 'All libraries' / 'All' / 'All' rule, set 'Recalls allowed (total)' 5, 'Recalls per record (count)' 5, 'On shelf recalls allowed' 'If any unavailable', 'Recall due date interval (day)' 3 4) Select 'Fairview', add a rule for 'All' categories / 'Books' with 'Recalls allowed (total)' 0 5) Edit item 39999000000795 of 'Robert Burns' (http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=18) and set its item type to 'Music' 6) Check out 39999000000771 (Books) to Sonia Frazier, due in 10 days 7) Check out 39999000000795 (Music) to Johnny Bryan, due in 20 days 8) Log into the OPAC as 'koha', go to http://localhost:8080/cgi-bin/koha/opac-recall.pl?biblionumber=18, pick 'Fairview' as pickup library and place the recall 9) Check both patrons' due dates: Johnny's loan has been shortened, Sonia's is unchanged. Without the patches it's the other way around, Sonia's (the one due soonest) gets shortened. 2) The atomicupdate uses Koha objects (Koha::Recalls, $recall->checkout) instead of plain SQL, as Marcel pointed out: https://wiki.koha-community.org/wiki/Database_updates#DBIx::Class. That's what led to 1). 3) Marcel also asked for tests, there are still none for the changes in Koha::Recalls->add_recall and Koha::Item->recall. Minor, but one would have caught that Koha::Item->recall now compares '$recall->item_id == $self->itemnumber' for record-level recalls whose item_id can still be NULL (e.g. after 'Revert waiting status'), which logs "Use of uninitialized value in numeric eq (==)" in plack-*error.log. -- You are receiving this mail because: You are watching all bug changes.