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

[Bug 26581] New: Elasticsearch - Records can be indexed multiple times during returns
by bugzilla-daemon＠bugs.koha-community.org 27 May '21

27 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26581 Bug ID: 26581 Summary: Elasticsearch - Records can be indexed multiple times during returns Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com Throughout add return we actually make several updates to the item: We set onloan -> null We update item location if pref says so We update datelast seen We update not for loan is pref says so etc. For ES, this means a new connection and a reindex each time. This is problematic -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 24541] New: Database cleanups, purge messages
by bugzilla-daemon＠bugs.koha-community.org 27 May '21

27 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24541 Bug ID: 24541 Summary: Database cleanups, purge messages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz misc/cronjobs/cleanup_database.pl provides some database cleanup. Yet some tables that could need cleanup are not in this script. Purge messages older than day (default 365). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 27790] New: Possibility to filter Holds to pull list using pickup place
by bugzilla-daemon＠bugs.koha-community.org 27 May '21

27 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27790 Bug ID: 27790 Summary: Possibility to filter Holds to pull list using pickup place Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Circulation Assignee: stalkernoid(a)gmail.com Reporter: stalkernoid(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Finnish libraries that we're supporting are actively using holds-to-pull feature, according to their reports, having ability to filter the table by "Pickup place" will help them be more efficient, as they often process those holds in batches by pickup places. They already tested that in the modified older version of Koha, and with plugin as well, which proved that they definitely need this feature and it helps libraries a lot. External reference for this request from Finnish libraries: https://tiketti.koha-suomi.fi/issues/4537 -- You are receiving this mail because: You are watching all bug changes.

1 15

[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 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

[Bug 18776] New: Translatability: Get rid of exposed tt directives in opac-advsearch.tt
by bugzilla-daemon＠bugs.koha-community.org 26 May '21

26 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18776 Bug ID: 18776 Summary: Translatability: Get rid of exposed tt directives in opac-advsearch.tt Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr The file opac-advsearch.tt exposes template directives to translation where translators should not be confronted with. Example in po file: "[%% IF ( ( OpacAdvSearchOptions and OpacAdvSearchOptions.grep('itemtype')." "size > 0 and not expanded_options ) or ( OpacAdvSearchMoreOptions and " "OpacAdvSearchMoreOptions.grep('itemtype').size > 0 and expanded_options ) ) " "%%] " -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 27724] New: Use lenient also in Elasticsearch authorities search
by bugzilla-daemon＠bugs.koha-community.org 25 May '21

25 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27724 Bug ID: 27724 Summary: Use lenient also in Elasticsearch authorities search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com In Elasticsearch, query for biblios uses lenient=true. This is also needed for authorities search. In case a search field is defined as type interger. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 28248] New: Exception when getting all orders
by bugzilla-daemon＠bugs.koha-community.org 25 May '21

25 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28248 Bug ID: 28248 Summary: Exception when getting all orders Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: somesecretemail(a)mailinator.com Making a get request against /api/v1/acquisitions/orders/ generates the following exception when aqorders.created_by is null i database [2021-04-28 14:10:21.48828] [600131] [warn] OpenAPI >>> GET api/v1/acquisitions/orders/ [{"message":"Expected integer - got null.","path":"\/0\/created_by"},{"message":"Expected integer - got null.","path":"\/1\/created_by"},{"message":"Expected integer - got null.","path":"\/2\/created_by"},{"message":"Expected integer - got null.","path":"\/3\/created_by"},{"message":"Expected integer - got null.","path":"\/4\/created_by"},{"message":"Expected integer - got null." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 23406] New: Authorized Value for Suppression when added to Frameworks doesn't show Suppress in Staff Client
by bugzilla-daemon＠bugs.koha-community.org 25 May '21

25 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23406 Bug ID: 23406 Summary: Authorized Value for Suppression when added to Frameworks doesn't show Suppress in Staff Client Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: training(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When cataloging records, the value of the 942$n if 1, Koha will suppress the record from the OPAC and also display a note on the staff client that this record is suppressed. The system preference: OPACsuppression should be set to Hide. To allow for more user-friendly cataloging, an authorized Value of Suppressed was created, the two values- 1- Suppress, 0 - Don't Suppress. This authorized value was added to the default framework for the 943$n in Other Options. Now when a cataloger wants to suppress a record when cataloging, they can have a drop-down menu to choose Suppress or Don't Suppress (versus remembering 1/0). Although this does work in suppressing the record from the OPAC, and when looking at the Marc Preview, the 942$n has the value 1, the staff client does not display a notification that this record is indeed suppressed. It would be nice if this process worked as regular suppression works- where this dropdown authorized value can be used and the note is visible in the staff client. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38