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

[Bug 27281] New: Replace call to `C4::Circulation::DeleteTransfer` with `Koha::Item::Transfer->cancel({ comment => $comment })` in `C4::Circulation::LostItem`
by bugzilla-daemon＠bugs.koha-community.org 27 May '21

27 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27281 Bug ID: 27281 Summary: Replace call to `C4::Circulation::DeleteTransfer` with `Koha::Item::Transfer->cancel({ comment => $comment })` in `C4::Circulation::LostItem` 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We should remove C4::Circulation::DeleteTransfer. We can use Koha::Item::Transfer->cancel in preference to it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 45

[Bug 26057] New: Transfers should record if they have been cancelled/overridden
by bugzilla-daemon＠bugs.koha-community.org 27 May '21

27 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26057 Bug ID: 26057 Summary: Transfers should record if they have been cancelled/overridden 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, jonathan.druart(a)bugs.koha-community.org, kyle.m.hall(a)gmail.com, sally.healey(a)cheshiresharedservices.gov.uk, testopia(a)bugs.koha-community.org Depends on: 23092 C4::Item::ModItemTransfer will silently cancel existing transfers by setting the datearrived and overwriting any data in the comment field with a cancellation note. For full audit purposes, we should record the 'cancellation', prevent the datarrived from being set and prevent data loss by not overwriting the original comment. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23092 [Bug 23092] Transfers should record 'requested' as well as 'sent' and 'arrived' dates -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 41

[Bug 11299] Add a button to automatically link authority records in cataloguing (AJAX)
by bugzilla-daemon＠bugs.koha-community.org 27 May '21

27 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11299 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |new feature -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7972] GUI for Crons
by bugzilla-daemon＠bugs.koha-community.org 27 May '21

27 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7972 Jonathan Druart <jonathan.druart+koha(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=1993 CC| |jonathan.druart+koha@gmail. | |com --- Comment #10 from Jonathan Druart <jonathan.druart+koha(a)gmail.com> --- An eventual implementation for this bug should have bug 1993 in mind. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 1993] Task Scheduler Needs Re-write
by bugzilla-daemon＠bugs.koha-community.org 27 May '21

27 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1993 Jonathan Druart <jonathan.druart+koha(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=7972 -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 15565] Place multiple item-level holds at once for the same record
by bugzilla-daemon＠bugs.koha-community.org 27 May '21

27 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15565 --- Comment #266 from David Cook <dcook(a)prosentient.com.au> --- I need to finish up for the day, but... I reckon we need something like this: Koha::Holds->remaining_reserves_total({ patron => $patron, }); maxreserves (global system preference) "Holds allowed (total)" (circ rule: reservesallowed) Koha::Holds->remaining_reserves_record({ patron => $patron, record => $biblio, }); "Holds per record (count)" (circ rule: holds_per_record) Koha::Holds->remaining_reserves_today({ patron => $patron, record => $biblio, }); "Holds allowed (daily)" (circ rule: holds_per_day) And each needs to consider an unlimited number (although in theory maxreserves should always be a positive integer). Then when you're checking boxes you check each of those totals in turn. (The reason for having separate functions is so that you can tell the user what limit they've exceeded...). An unlimited rule should probably return a null response, so that you only consider counts that are digits. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15565] Place multiple item-level holds at once for the same record
by bugzilla-daemon＠bugs.koha-community.org 27 May '21

27 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15565 --- Comment #265 from David Cook <dcook(a)prosentient.com.au> --- Ok so there are 4 different settings that control the allowable number of holds: maxreserves (global system preference) "Holds allowed (total)" (circ rule: reservesallowed) "Holds allowed (daily)" (circ rule: holds_per_day) "Holds per record (count)" (circ rule: holds_per_record) C4::Reserves is a mess... If the following are blank/empty (notably not null), then 15565 doesn't work. select * from circulation_rules where rule_name IN ('reservesallowed', 'holds_per_day', 'holds_per_record'); -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15565] Place multiple item-level holds at once for the same record
by bugzilla-daemon＠bugs.koha-community.org 27 May '21

27 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15565 --- Comment #264 from David Cook <dcook(a)prosentient.com.au> --- Test plan: 0) git bz apply 15565 1) restart_all 2) Set up a record with 4 items E.g. add 3 items to http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=29 Staff Interface: 3) Set the maxreserves system preference to 2 (from 50) 4) Go to http://localhost:8081/cgi-bin/koha/reserve/request.pl?borrowernumber=51&bib… 5) Try to place a hold on all the items Unfortunately, as soon as I choose 1 item, it says "Patron reached the maximum number of holds". It looks like these patches don't work with "Unlimited" holds, so this functionality is fundamentally broken... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 27 May '21

27 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 --- Comment #330 from David Cook <dcook(a)prosentient.com.au> --- I can look at fixing up some of those QA errors as they're very minor. I can take a look at the maxreserves thing too although that might be more complex.. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 24553] New: Cancelling hold via SIP returns a failed response even when cancellation succeeds
by bugzilla-daemon＠bugs.koha-community.org 26 May '21

26 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24553 Bug ID: 24553 Summary: Cancelling hold via SIP returns a failed response even when cancellation succeeds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com It looks like we have some odd code here. We delete the hold (C4::SIP::ILS::Transaction::Hold->drop_hold), then we check the patron to see if they have a hold on the item (C4::SIP::ILS::Patron->drop_hold) - of course we don't find the hold because we already cancelled it. 348 $trans->patron($patron); 349 $trans->item($item); 350 $trans->drop_hold; 351 unless ($trans->ok) { 352 $trans->screen_msg("Error with transaction drop_hold: " . $trans->screen_msg); 353 return $trans; 354 } 355 # Remove the hold from the patron's record first 356 $trans->ok($patron->drop_hold($item_id)); # different than the transaction drop! 357 358 unless ($trans->ok) { 359 # We didn't find it on the patron record 360 $trans->screen_msg("No such hold on patron record."); 361 return $trans; 362 } -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26