July 2024 - Koha-bugs - lists.koha-community.org

[Bug 18194] New: Elasticsearch should be able to add new indexes
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '24

09 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18194 Bug ID: 18194 Summary: Elasticsearch should be able to add new indexes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 14899 added a configuration page for elastic search indexes. It would be nice to allow for the addition/deletion of indexes as well as their configuration -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 23357] New: overdue_notices.pl can send library doubled emails for patrons with no email/sms if both transports enabled
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '24

09 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23357 Bug ID: 23357 Summary: overdue_notices.pl can send library doubled emails for patrons with no email/sms if both transports enabled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz In overdue_notices.pl we have a check to avoid sending a patron two notices if they are missing an email address and an sms number, however, we don't apply this check to generating the notice content and so send the library the same info twice -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 23497] New: Notices defaulting to print
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '24

09 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23497 Bug ID: 23497 Summary: Notices defaulting to print Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Why is it that Koha defaults to printing? Shouldn't the default be no notification, and we have to select which notices are printed, if any? Right now, if a patron doesn't have an e-mail selected as the form of notification, the notice defaults to print. I would like to suggest that a print column be added, and if nothing is checked, nothing is generated. Maybe in the notices tab for the patron a place holder could be made saying that patron opted for no notification, or something like that? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 32626] New: [Omnibus] Improve REST API for ILL
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '24

06 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32626 Bug ID: 32626 Summary: [Omnibus] Improve REST API for ILL Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de CC: tomascohen(a)gmail.com Depends on: 23559, 23561 There are several bugs about the REST API in the ILL component. Adding this bug to serve as an omnibus for future work. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23559 [Bug 23559] REST API: Overwrite an ILL request https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23561 [Bug 23561] REST API: Partially update an ILL request -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 23558] New: REST API: Get an ILL request
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '24

06 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23558 Bug ID: 23558 Summary: REST API: Get an ILL request Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: black23(a)gmail.com Method GET /ill_requests/{ill_request_id} https://wiki.koha-community.org/wiki/Illrequests_endpoint_RFC -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 22440] New: ILL API response objects inconsistent with other endpoints
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '24

06 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22440 Bug ID: 22440 Summary: ILL API response objects inconsistent with other endpoints Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com Target Milestone: --- The response object returned from the /api/vi/illrequest GET route isn't consistent with response objects supplied by other routes, such as the patrons route. We have an RFC for this route here: https://wiki.koha-community.org/wiki/Illrequests_endpoint_RFC Josef has made some initial recommendations on what the properties should be named to make them consistent with other routes. We could do with expanding this RFC to make it complete, including a spec on how object embedding should be done since, to date, this is the only route that does this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 66

[Bug 23557] New: REST API: Add ILL request
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '24

06 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23557 Bug ID: 23557 Summary: REST API: Add ILL request Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: black23(a)gmail.com Method POST /ill_requests https://wiki.koha-community.org/wiki/Illrequests_endpoint_RFC -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 26715] New: Make Z39.50 modal moveable in the Advanced Cataloging Editor
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '24

06 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26715 Bug ID: 26715 Summary: Make Z39.50 modal moveable in the Advanced Cataloging Editor Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be helpful to be able to move the Z39.50 modal around the screen when performing a Z39.50 search while editing a record in the Advanced Cataloging Editor (editor.p) Sometimes after doing the Z39.50 search you need to see something in the original bib record and it ends up being obscured behind the modal causing you to have to close the modal in order to view the specific part of the bib record you needed to consult. Then you have to re-execute the Z39.50 search. It would be a great timesaver if you could move the modal around the screen to view all parts of the bib record behind it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 36613] New: Wrong return statuses on merge biblio feature
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '24

06 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36613 Bug ID: 36613 Summary: Wrong return statuses on merge biblio feature Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Bug 33036 introduced a feature for merging records using the API. But some of the return statuses are wrong: ```perl if ( ( $rules eq 'override_ext' ) && ( $override_rec eq '' ) ) { return $c->render( status => 404, json => { error => "With the rule 'override_ext' you need to insert a bib record in marc-in-json format into 'record' field." } ); } if ( ( $rules eq 'override' ) && ( $framework ne '' ) ) { return $c->render( status => 404, json => { error => "With the rule 'override' you can not use the field 'framework_to_use'." } ); } ``` Both should be '400 - Bad request' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 27677] New: Configure facets differently for OPAC and Staff Client
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '24

06 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27677 Bug ID: 27677 Summary: Configure facets differently for OPAC and Staff Client Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr Search logics and needs are different if you are a user or a librarian. It could be great if we could define two different orders for the facets for the OPAC and the staff client, and if we could hide/show a facet in an interface but not the other one. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2