August 2023 - Koha-bugs - lists.koha-community.org

[Bug 32515] New: SIP2 no block flag on checkin calls routine that does not exist
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32515 Bug ID: 32515 Summary: SIP2 no block flag on checkin calls routine that does not exist 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 git grep "checkin_no_block" C4/SIP/Sip/MsgType.pm: $status = $ils->checkin_no_block( $item_id, $trans_date, $return_date, $item_props, $cancel ); -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 18117] New: Convert browser alerts to modals
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18117 Bug ID: 18117 Summary: Convert browser alerts to modals Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org With modals becoming more active in Koha, I think we need to move away from alert messages and stick with modals. Alert messages look different from browser to browser, and you have less/no control over the look and feel of the alert. Modals would allow for more enhancement, such as color and sound, if someone chose that. The big concern is consistency. We lack consistency between alerts and modals, and with alerts between browsers. I would proposed a stop on use of alert messages, and convert existing uses of alerts to modal. That's my opinion. Would like to hear others. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 30575] New: Returning an ILL item shouldn't just change the request status
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30575 Bug ID: 30575 Summary: Returning an ILL item shouldn't just change the request status 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: tomascohen(a)gmail.com In the context of more complex ILL backends, in which returning an item could imply, for example, notifying an external source it is just not enough to call $req->status('RET')->store We should be calling something like ->backend_return instead, as we do with other actions, and let the plugin handle it however they need to. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 32627] New: Reprinting holds slips should not reset the expiration date
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32627 Bug ID: 32627 Summary: Reprinting holds slips should not reset the expiration date Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Occasionally, the slips in items waiting on the holds shelf tend to get pulled out. When this happens, library staff check in items to reprint the slips. Previous to the latest upgrade the holds expiration date would remain the same, but now the expiration date is being calculated based on the NEW date the item is checked in. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 27849] New: Koha::Token may access undefined C4::Context->userenv
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27849 Bug ID: 27849 Summary: Koha::Token may access undefined C4::Context->userenv Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: mjr(a)software.coop QA Contact: testopia(a)bugs.koha-community.org The _add_default_csrf_params internal function accesses C4::Context->userenv without checking that it has been defined. I think not all of the potential callers of it declare that they require a defined userenv, so we should test and provide defaults for required values if it is not defined, to avoid some "Can't use an undefined value as a HASH reference" HTTP 500 Internal Server Errors. Step to Reproduce: write some code that results in that function being used before a set_userenv call Actual Result: error logged, code exits Expected Result: code runs to completion Additional Information: I am not sure whether this is currently triggered by any released core koha code, or only a few plugins and mods. It looks to me like a bug waiting to happen, based on the documentation, which can be avoided simply. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 16514] New: Force scalar cotext where param assumes a list incorrectly in admin/edi scripts
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '23

11 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16514 Bug ID: 16514 Summary: Force scalar cotext where param assumes a list incorrectly in admin/edi scripts Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: colin.campbell(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CGI's param method assumes a list context when lvalue not explicitly scalar. Force the correct context to avoid errors being logged -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 18158] New: Make SIP2 title identifier (AJ) customizable within sipconfig.xml
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '23

11 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18158 Bug ID: 18158 Summary: Make SIP2 title identifier (AJ) customizable within sipconfig.xml Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Feature Request: Add the ability to customize SIP2 title identifier (AJ) returned in Checkout Response (12) Checkin Response(10) Item Information Response (18) Hold Response (16) Renew Response (30) The formatting could be done by adding template toolkit code to sipconfig.xml, as was done in Bug 16755 - allow SIP2 field DA ( hold patron name ) to be customized. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 34170] New: Ability to add record/order line specific credits
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '23

11 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34170 Bug ID: 34170 Summary: Ability to add record/order line specific credits Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org With invoice adjustments it's possible to enter negative values to indicate a credit (see bug 19166). The problem is, that while these are linked to a specific invoice, there is no way to link an invoice adjustment to a specific order line or record. The credits might be granted after the initial invoice, because an order has been cancelled mid-term or because of a special discount that was applied. In order to be able to calculate the correct cost in that case, we need to be able to link it to a record or order line. One way this could be achieved would be to allow negative prices on ordering. At the moment when you enter a negative list price, it's stored correctly into the database, but won't be used correctly for calculations and the minus signs is lost in display. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 32275] New: Fill blank record in basic editor using ISBN with Google Books API
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '23

11 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32275 Bug ID: 32275 Summary: Fill blank record in basic editor using ISBN with Google Books API Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jrobb(a)sekls.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bug 14242 added the ability to fill the OPAC purchase suggestion form with data from the Google Books API by entering an ISBN. My catalogers would be ecstatic if that functionality could be used to populate the relevant fields on a blank bib record in the basic editor as a starting point for creating records from scratch. This would save a substantial amount of time entering data. Logical mappings would be: volumeInfo.title > 245$a volumeInfo.subtitle > 245$b volumeInfo.authors > 100$a volumeInfo.publisher > 264$a volumeInfo.publishedDate > 264$c volumeInfo.pageCount > 300$a volumeInfo.dimensions.height > 300$c volumeInfo.description > 500$a -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 18161] New: Option to completely disable advance notice on loans with auto renewal
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '23

11 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18161 Bug ID: 18161 Summary: Option to completely disable advance notice on loans with auto renewal Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: stefan.berndtsson(a)ub.gu.se QA Contact: testopia(a)bugs.koha-community.org Some background. In our current library system, we use long loans (loans with a guaranteed minimum due date, but a much much longer hard due date), with a recall function. This is only in use for parts of the content. Koha does not support this, so we're looking at using auto renewal as a method to give a reasonable resemblance of long loans. We also want advance notices to be sent when the due date is about to arrive, but having an advance notice and then an automatic renewal shortly after will produce a multitude of notices that will be considered as faulty by the end user. The suggested solution to this is an option to simply disable advance notices for loans where auto renewal is active. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7