May 2025 - Koha-bugs - lists.koha-community.org

[Bug 33990] New: Fix the 'Recalls awaiting pickup' report if there are recalls waiting a problematic number of days
by bugzilla-daemon＠bugs.koha-community.org 29 May '25

29 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33990 Bug ID: 33990 Summary: Fix the 'Recalls awaiting pickup' report if there are recalls waiting a problematic number of days Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The Recalls awaiting pickup report blows up if a recall has been waiting a problematic number of days for pickup. This is based on the RecallsMaxPickUpDelay system preference. To reproduce: 1. Enable UseRecalls syspref and set the relevant circulation and fines rules to configure recalls 2. Set the RecallsMaxPickUpDelay to 1 day 3. Check out Item A to Patron A 4. Log into the OPAC as Patron B 5. Search for Item A and place a recall 6. Log back into the staff interface and check in Item A 7. Confirm the recall as waiting for Patron B 8. Go to Circulation -> Recalls awaiting pickup 9. Confirm your recall exists under the 'Recalls waiting' tab 10. Change the waiting_date in the database for this recall to a few days ago so we would expect to see it under the 'Recalls waiting over 1 days' tab sudo koha-mysql INSTANCE select * from recalls; # to get the recall_id update recalls set waiting_date = "2023-06-10 03:54:21" where recall_id = X; 11. Refresh the Circulation -> Recalls awaiting pickup page 12. Confirm the page blows up and there is an error -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 33992] New: Only consider the date when labelling a waiting recall as problematic
by bugzilla-daemon＠bugs.koha-community.org 29 May '25

29 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33992 Bug ID: 33992 Summary: Only consider the date when labelling a waiting recall as problematic Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The recalls awaiting pickup report has two tabs - recalls waiting, and recalls waiting over X days. This number of days when a recall is labelled 'problematic' is defined by the RecallsMaxPickUpDelay system preference. Sometimes recalls do not show here even when we would expect them to. This is because the waiting_date for recalls is a timestamp, and Koha wrongly considers the time when deciding if the recall has been waiting for a problematic number of days. For example, consider this set up: - RecallsMaxPickUpDelay = 1 day - Recall has been waiting since 12 June - Today is 13 June Treating 12 June as 1 day, the recall has been awaiting pickup for more than 1 day, so I would expect it to show under the 'recalls waiting over X days' tab. It doesn't, because when we look at the database timestamps: - Recall has been waiting since 2023-06-12 19:06:58 - Time now is 2023-06-13 17:06:58 - Recall waiting_date plus 1 max pickup delay day equals 2023-06-13 19:06:58 - which is 2 hours after the cut off to be considered problematic. Koha should not consider the timestamp in this case, it should only look at the date -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 32967] New: Recalls notices are using the wrong database columns
by bugzilla-daemon＠bugs.koha-community.org 29 May '25

29 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32967 Bug ID: 32967 Summary: Recalls notices are using the wrong database columns Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org The recalls table column names were changed before they were upstreamed but this change wasn't carried over to the notices. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 33220] New: Recalls to pull should not show in transit or allocated items
by bugzilla-daemon＠bugs.koha-community.org 29 May '25

29 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33220 Bug ID: 33220 Summary: Recalls to pull should not show in transit or allocated items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Recalls to pull report does not show accurate information. Recalled items that are in transit should not show on the recalls to pull page, as the item has been allocated already, and it's not on the shelf ready to pull. To reproduce: 1. Check out Item A to Patron A. Item A should be the only item on Biblio A (pick a record with only one item, or create a record with one item). 2. Log into the OPAC as Patron B 3. Place a recall on Item A for Patron B. Change the pickup library so it isn't your default library 4. Log back into the staff interface 5. Check in Item A, make sure you're not logged into the selected pickup library so we trigger a transfer. 6. Confirm the recall and transfer. 7. Go to Circulation -> Recalls to pull. Notice the recall shows here, even though it is not ready to pull. Also, for records that have multiple recalls, the information may show wrongly on recalls to pull. To reproduce: 1. Cancel any recalls on Item A/Biblio A. 2. Check out Item A to Patron A. Item A should be the only item on Biblio A (pick a record with only one item, or create a record with one item). 2. Log into the OPAC as Patron B. 3. Place a recall on Item A for Patron B. 4. Log into the OPAC as Patron C. 5. Place a recall on Item A for Patron C. Item A should now be checked out to Patron A, with two recalls on it for Patrons B and C. 6. Log back into the staff interface. 7. Check in Item A. Confirm the recall as waiting for Patron B. 8. Go to Circulation -> Recalls to pull. Notice the recall for Patron C shows here, even though the one item that could fill this recall has already been allocated to Patron B. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 32268] New: t/db_dependent/XSLT.t is failing randomly
by bugzilla-daemon＠bugs.koha-community.org 29 May '25

29 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32268 Bug ID: 32268 Summary: t/db_dependent/XSLT.t is failing randomly Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 19532 Blocks: 25551 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=25551 [Bug 25551] [OMNIBUS] Some tests are failing randomly -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 32445] New: Status display of 'not for loan' items is broken in OPAC/staff
by bugzilla-daemon＠bugs.koha-community.org 29 May '25

29 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32445 Bug ID: 32445 Summary: Status display of 'not for loan' items is broken in OPAC/staff Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org This is a display issue, but marking as major since it affects a basic functionality in the OPAC: 1) Edit any item, item type should be for loan, so not set to reference. 2) Set Not for loan status to "not for loan". 3) Go to the staff detail page: 4) Verify it displays as: Not for loan (Not For Loan) Available The available should not be there! 5) Go to the OPAC detail page: 6) Verifiy the status displays as: Available This should display the not for loan status! -- You are receiving this mail because: You are watching all bug changes.

1 67

[Bug 31147] New: Recalls due date to the minute rather than 23:59
by bugzilla-daemon＠bugs.koha-community.org 29 May '25

29 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31147 Bug ID: 31147 Summary: Recalls due date to the minute rather than 23:59 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I don't know if this is intended behaviour or a bug. When placing a recall, the new due date is exactly now + recall due date interval. Let's say my recall due date interval is 7 and an item is due 2022-08-31 23:59:00. If I place my recall today (2022-07-12) at 16:31:14, the new due date will be 2022-07-19 16:31:14. Like I said, I'm not sure if this is the intended behaviour, but in my very unknowledgable opinion, I find it a bit extreme to ask someone out of the blue to return an item by a certain time (to the second). To test: 1) Turn on recalls 1.1) In Administration > Global system preferences, enable UseRecalls 1.2) Add recalls permissions in your circulation rules 2) Find a record with a checked out item; check the due date for that checked out item, e.g. SELECT date_due FROM issues WHERE itemnumber = XXXX; --> It should be YYYY-MM-DD 23:59:00 3) In the OPAC, log in as a patron 4) Find the same record and place a recall 5) Check the new due date --> It should be today + the number of days you put in recall due date interval in step 1.2 at the exact time you placed the recall -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 32129] New: Use patron categorycode of most relevant recall when checking if item can be a waiting recall
by bugzilla-daemon＠bugs.koha-community.org 29 May '25

29 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32129 Bug ID: 32129 Summary: Use patron categorycode of most relevant recall when checking if item can be a waiting recall Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We check in (return) an item to trigger the recalls process and set it as waiting for the patron who requested the recall. Sometimes the recalls process isn't triggered, and there is no other way to alert the patron that their item is ready for them to pick up if they've recalled it. This is because of more specific circulation rules. When we check if an item can be set as waiting to fill a recall, we do not consider the category code. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 30907] New: List of checkouts won't load if item is recalled
by bugzilla-daemon＠bugs.koha-community.org 29 May '25

29 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30907 Bug ID: 30907 Summary: List of checkouts won't load if item is recalled Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 19532 When an item on the patron account was recalled, the list of checkouts in the patron account in the staff interface doesn't load: XHRGEThttp://localhost:8081/cgi-bin/koha/svc/checkouts?borrowernumber=19&_=1654512131603 [HTTP/1.1 500 Internal Server Error 223ms] The method Koha::Recall->item_level_recall is not covered by tests! I have tried with several of the other recall fixes applied, but couldn't get this to go away. If it's a duplicate please close. 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 the assignee for the bug. You are watching all bug changes.

1 25

[Bug 30886] New: Recall status cannot be correct on opac-detail
by bugzilla-daemon＠bugs.koha-community.org 29 May '25

29 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30886 Bug ID: 30886 Summary: Recall status cannot be correct on opac-detail Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 19532 734 my $recall_status; 735 if ( C4::Context->preference('UseRecalls') ) { 736 my $recall_status = Koha::Recalls->search( 737 { 738 item_id => $itm->{itemnumber}, 739 status => 'waiting', 740 completed => undef, 741 } 742 )->count; 743 } Extra "my" here. 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 the assignee for the bug. You are watching all bug changes.

1 21