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

[Bug 20850] New: Option to delete all items on bib that have a -1 Not-for-loan value when doing a MARC import
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '23

16 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20850 Bug ID: 20850 Summary: Option to delete all items on bib that have a -1 Not-for-loan value when doing a MARC import Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: hughr(a)brimbank.vic.gov.au QA Contact: testopia(a)bugs.koha-community.org It would be nice to expand on Bug 7131 by providing an option to delete all 'on order' items on a bib when importing. This would allow for 'overlaying' of order items with full item records when it is not possible to assign either a matching barcode or a matching item number in the file being imported. This could be done by checking the Not-For-Loan value: if it is -1 then the item is an on-order item and can safely be removed. This would obviously not suit all library workflows and could be dangerous for some, so would need to be either a syspref or an option to select during import, or both. Admins or librarians could choose whether to always delete items with NFL = -1, or only do so if they also do not have a barcode. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 24307] New: Allow loose item matching for on-order items
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '23

16 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24307 Bug ID: 24307 Summary: Allow loose item matching for on-order items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We run into this issue with libraries who are not using EDI, get their items pre-processed by a vendor, and want on-order items to show in the catalog: - MARC records are imported for on-order titles - On-order items are created - Vendor sends final MARC records including 952 tags with barcode, ccode, location, etc - Final records match to existing records at the bib level, but cannot match at the item level - Item records need to be manually touched either to add final details to on-order items or to delete on-order items in favor of newly-created final items The vendor cannot give a barcode number when supplying on-order records and (without EDI) Koha doesn't have a way to send the on-order item numbers to the vendor to be included in the final item info. I'm imagining something like a syspref that lets us say "if an item has notforloan of [X], then allow item overlay without matching an itemnumber or barcode." But as I type that I suspect there are a lot of ways it could go bad. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 20856] New: Restore ability to delete unverified self registrations after x hours
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '23

16 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20856 Bug ID: 20856 Summary: Restore ability to delete unverified self registrations after x hours Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com With bug 13049 the behaviour of the was changed, so the number of hours defined for will be recalculated into days now (minimum 1). It would be nice if it was possible again to give the delay in hours. But we should at least change the help of delete_unverified_opac_registrations.pl to point out that limitation. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 20860] New: List last e-mail address/SMS number/carrier sent to
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '23

16 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20860 Bug ID: 20860 Summary: List last e-mail address/SMS number/carrier sent to Change sponsored?: --- Product: Koha Version: 17.05 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 It would be helpful if the notifications listed the last e-mail address or SMS number and carrier that each notice was sent to. That way we know if the information was changed before/after the last failure. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 29292] New: Notices does not record what address or number was used
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '23

16 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29292 Bug ID: 29292 Summary: Notices does not record what address or number was used 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 It would be great if we could see what e-mail address or phone number or sms number, or mailing address was used to send a notice on the last attempt. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 30286] New: Notices.pl does not show what number or e-mail it used
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '23

16 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30286 Bug ID: 30286 Summary: Notices.pl does not show what number or e-mail it used Change sponsored?: --- Product: Koha Version: 21.11 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 It would be helpful to see what number or address was used when a notice was last sent (or failed) in notices.pl. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 20868] New: Making billing date mandatory when closing invoice
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '23

16 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20868 Bug ID: 20868 Summary: Making billing date mandatory when closing invoice Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: information(a)newcastle.gov.uk QA Contact: testopia(a)bugs.koha-community.org Would it be possible to make the billing date a mandatory field before you close an invoice for payment? Thanks -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 20901] New: Koha/Patrons/Import.t fails on fresh database
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '23

16 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20901 Bug ID: 20901 Summary: Koha/Patrons/Import.t fails on fresh database Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org t/db_dependent/Koha/Patrons/Import.t # Looks like you failed 58 tests of 124. Fresh install, no optional stuff -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 20908] New: Print receipts need clean up
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '23

16 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20908 Bug ID: 20908 Summary: Print receipts need clean up Change sponsored?: --- Product: Koha Version: master 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: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org During work on bug 20903, I realize the need of clean up of print receipts scripts and templates... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 20932] New: Add multiple items should have a maximum number to be able to add at a time
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '23

16 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20932 Bug ID: 20932 Summary: Add multiple items should have a maximum number to be able to add at a time Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Command-line Utilities Assignee: nick(a)bywatersolutions.com Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Currently, when adding items to an existing record- the option is to add item, duplicate or add multiple items. When the option is chosen for adding multiple items, there is a box displayed that a quantity can be entered. If the number is large (above 100) there is a pop-up message confirming this many. In addition to the pop-up, it would be helpful for a system preference to set a maximum number for this feature -as it is with Batch Item Modification / Batch Item Deletion. -- You are receiving this mail because: You are watching all bug changes.

1 3