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

[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 07 Sep '24

07 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 07 Sep '24

07 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 07 Sep '24

07 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 07 Sep '24

07 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

[Bug 29606] New: Include items from host record in XML for XSLT processing
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '24

06 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29606 Bug ID: 29606 Summary: Include items from host record in XML for XSLT processing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Searching Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org If EasyAnalyticalRecords is enabled, items from host records should be included in the XML. Otherwise, OPAC search results show no items. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 29689] New: Update to 21.11 broken auto-generated barcode in <branchcode>0001 option
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '24

06 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29689 Bug ID: 29689 Summary: Update to 21.11 broken auto-generated barcode in <branchcode>0001 option Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jmhenrique(a)yahoo.com.br QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 128480 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=128480&action=e… Error in Chrome console Hi! In version 21.05 the automatic barcode generator for manual addition of items worked. When upgrading to 21.11, it stopped working. The chrome debug shows the following message attached To reproduce the error, clicking on the item "p - barcode" generates the error on the console, and does not show any expected results. The autoBarcode option is set to "<branchcode>yymm0001" . Other autoBarcode options work except "<branchcode>aamm0001" . -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29