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

[Bug 33305] New: Standing orders: Allow to link received item to another bibliographic record on receive
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '24

05 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33305 Bug ID: 33305 Summary: Standing orders: Allow to link received item to another bibliographic record on receive 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: michaela.sieber(a)kit.edu At the moment we use standing orders for multi-volume and series ordering mostly. The order is placed on the set or traced series record. When a part of the series is delivered and received, the order line will still be linked to the set records. This makes all acquisition information appear on the set record, instead of the parts. If you are using items, you can use the "attach item" feature, to change it to the record of the part, but this means a lot of additional clicks. It will also not work if you are not creating items in acq. It would be nice, if you could link the received order line to the correct part as part of the receiving process. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 34576] New: wrong information about use of 942 in unimarc
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '24

03 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34576 Bug ID: 34576 Summary: wrong information about use of 942 in unimarc Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org In https://koha-community.org/manual/23.05/en/html/cataloging.html#added-entry… it is said that 942$2,$6 and $c is used in UNIMARC installation in the same way as MARC21 It is not the case in my (unimarc) library, and it is not what is written in the wiki https://wiki.koha-community.org/wiki/Holdings_data_fields_(9xx) Is it hardcoded somewhere in Koha ? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 32435] New: Add resolution types to catalog concerns
by bugzilla-daemon＠bugs.koha-community.org 02 Aug '24

02 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32435 Bug ID: 32435 Summary: Add resolution types to catalog concerns 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 31028 It would be nice to have a descriptive resolution text for different standard resolutions to catalog problems reported via the new catalog concerns feature. We're envisaging using the authorized values system to populate a drop down of resolutions available. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31028 [Bug 31028] Add 'Report a concern' feature for patrons to report concerns about catalog records -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 65

[Bug 15854] New: Possible race condition for sending renewal notices
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '24

01 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15854 Bug ID: 15854 Summary: Possible race condition for sending renewal notices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Renewal notices are sent as digests - all renewed items are collected in one e-mail that is sent out with the process_messagequeue. We have a library, where sometimes this doesn't work. Instead of one single e-mail notice to the patron for one 'process_messagequeue' interval, multiple renewal notices are generated. The majority of e-mails is generated correctly. Looking at the code, this is about how it works: - AddRenewal is exectuted per item and calls - SendCirculationAlert which calls - C4::Message->find_last_message to help decide if a new notice has to be generated or an existing one can be amended In order to test this, you need: - EnhancedMessagingPreferences - Check-out notice checked for the patron you test with - RenewalSendNotice activated - A notice called RENEWAL As I see no problem in the logic so far, I think it could be a race condition where find_last_message doesn't find an existing notice (yet)? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 24007] New: Koha::Account::non_issues_charges is badly named
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '24

01 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24007 Bug ID: 24007 Summary: Koha::Account::non_issues_charges is badly named Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org The non_issues_charges method name suggests you will be returned a set of charges (Account::Lines) which would block a patrons ability to check out items. In fact, it returns a 'balance' of such charges but includes outstanding credits in the calculation. We should either rename the method to clarify it's use or update the method to return the expectation given it's naming. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 24009] New: Koha::Account->outstanding_debits should support inline filtering
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '24

01 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24009 Bug ID: 24009 Summary: Koha::Account->outstanding_debits should support inline filtering Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org We have a number of places where we want to get a specific list of outstanding debits for comparison.. at the moment one would have to construct a search directly by inspecting system preferences at the controller level. By addins a filter option to oustanding_debits we can move that back to the object level without having to add additional methods. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 30654] New: Even with RabbitMQ enabled, we should poll the database for jobs at worker startup
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '24

01 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30654 Bug ID: 30654 Summary: Even with RabbitMQ enabled, we should poll the database for jobs at worker startup Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 27344 Our worker currently starts up and immediately tries to listen for jobs being passed via STOMP. However, if rabbitMQ wasn't running when the tasks were enqueue, then the worker will never know about them. We should work through the outstanding queue before listening for new jobs. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27344 [Bug 27344] Implement Elastic's update_index_background using Koha::BackgroundJob -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 35189] New: Itemtypes SVG icons should be limited in height/width
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '24

30 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35189 Bug ID: 35189 Summary: Itemtypes SVG icons should be limited in height/width Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: pablo.bianchi(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 158067 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=158067&action=e… Screenshot Steps to reproduce the issue: 1. On Staff interface, on Administration > Item types, modify any item 2. Choose an SVG image as a remote image for an Item type, for eg https://raw.githubusercontent.com/FortAwesome/Font-Awesome/afecf2af5d897b76… Save changes. When listed on itemtypes.pl the icon is not too big, but if you edit again the itemtype (using above SVG, more than 1200px width). This also impact at some degree on Advanced search (staff and OPAC, search.pl, opac-search.pl). -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 35155] New: MARCOverlayRules syspref not in manual
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '24

30 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35155 Bug ID: 35155 Summary: MARCOverlayRules syspref not in manual Change sponsored?: --- Product: Koha Version: unspecified Hardware: All URL: https://gitlab.com/gnucifer/koha-manual/-/commit/593c5 da008dbc4b074cac9dee167cce9a6dfc250#c5e2c75dc923f21c5b 95185b2f350df00fec661f OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 14957 MARCOverlayRules system pref and functionality introduced in 21.11 never made it into Koha manual. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957 [Bug 14957] Write protecting MARC fields based on source of import -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 25610] New: Inconsistent display of 856$3 in OPAC between brief result and full record
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '24

30 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25610 Bug ID: 25610 Summary: Inconsistent display of 856$3 in OPAC between brief result and full record Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently, if a record has an 856$3, this will show in the brief results and not in the full results. It should be consistent between the two views. And what is the opinion that the $3 should show or should not? For decisions like these, it would be nice for the library to decide what is displayed and allow for changes to be made through the staff client vs XSLT stylesheets. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3