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

[Bug 22712] New: Funds from inactive budgets appear on Item details if using MarcItemFieldstoOrder
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22712 Bug ID: 22712 Summary: Funds from inactive budgets appear on Item details if using MarcItemFieldstoOrder Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Created attachment 88047 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=88047&action=ed… drop down Bug 14850 has been fixed and patched for 18.11. This removes the ability to see inactive funds when allocating orders to these funds from an inactive budget. However, if a library is using the system preference MarcItemFieldstoOrder, all the funds will appear in the drop-down menu for that item record. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 34966] New: Terminology: Item add form - "Add & duplicate" should be "Add and duplicate"
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34966 Bug ID: 34966 Summary: Terminology: Item add form - "Add & duplicate" should be "Add and duplicate" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In our terminology guide, & should only be used when it is part of a proper noun or a common abbreviation: https://wiki.koha-community.org/wiki/Terminology The add item form in the staff interface incorrectly use "Add & duplicate" (New > New item). To replicate: 1. In the staff interface, search for and select a record. 2. Select New > New item. 3. Note that "Add & duplicate" is one of the action buttons at the bottom of the add item form. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 34954] New: Typo: datexpiry
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34954 Bug ID: 34954 Summary: Typo: datexpiry 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: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org $ grep -rn --exclude=*.po "datexpiry" * grep: how-to.pl: No such file or directory koha-tmpl/intranet-tmpl/prog/en/modules/tools/import_borrowers.tt:321: <option value="">using the datexpiry value in the file, if present</option> koha-tmpl/intranet-tmpl/prog/nb-NO/modules/tools/import_borrowers.tt:312: <option value="">using the datexpiry value in the file, if present</option> misc/release_notes/release_notes_18_05_00.html:792:<li><a href="http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20145">[20145]</a> borrowers.datexpiry eq '0000-00-00' means expired?</li> misc/release_notes/release_notes_18_05_00.md:629:- [[20145]](http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20145) borrowers.datexpiry eq '0000-00-00' means expired? t/db_dependent/Koha/Patrons/Import.t:1204: "Expiration date is correct with update_dateexpiry = true no dateexpiry in file and update_datexpiryfromtoday false (i.e. use passed dateenrolled) " t/db_dependent/Koha/Patrons/Import.t:1217: "Expiration date is correct with update_dateexpiry = true no dateexpiry in file and update_datexpiryfromtoday true " t/db_dependent/Koha/Patrons/Import.t:1231: "Expiration date is correct with update_dateexpiry = true no dateexpiry in file and update_datexpiryfromtoday false but no dateenrolled in file (today is used) " "dateexpiry" is used everywhere else. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 34678] New: Real-time holds queue updates can cause the holds queue builder cron to fail
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34678 Bug ID: 34678 Summary: Real-time holds queue updates can cause the holds queue builder cron to fail Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In bug 34656, it came to light that, if a real-time holds queue update and the holds queue builder cron try to update the same bib at the same time, it can cause the cron to fail. Specifically, if a real-time update adds a particular item to hold_fill_targets, and the holds queue builder tries to add the same item afterwards, the cron will fail with an error like: C4::HoldsQueue::AddToHoldTargetMap(): DBI Exception: DBD::mysql::st execute failed: Duplicate entry '464273' for key 'PRIMARY' at /usr/share/koha/lib/C4/HoldsQueue.pm line 1015 The biggest issue here is that any remaining holds that the cron has not yet processed will be left out of the holds queue until something else triggers them to update. (in our system, the issue in bug 34656 was occurring regularly, and typically left over 1,000 holds out of the holds queue!) If the holds queue builder can be forced to run while RealTimeHoldsQueue is enabled, it needs a way to avoid crashing if a real-time update happens to add a bib back into the queue before the queue builder gets to it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

[Bug 33810] New: Accessibility: OPAC Advanced Search fields are not labelled
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33810 Bug ID: 33810 Summary: Accessibility: OPAC Advanced Search fields are not labelled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: matt.blenkinsop(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org The OPAC Advanced Search fields are not labelled and have been failed in an Accessibility report carried out by the Shaw Trust for the British Museum. The search field dropdowns do not have any labelling at all and the text inputs have a title, rather than a label element or an aria-label. -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 32856] New: Fix cataloguing/value_builder/unimarc_field_126.pl
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32856 Bug ID: 32856 Summary: Fix cataloguing/value_builder/unimarc_field_126.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: trivial Priority: P5 - low Component: Cataloging Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Blocks: 30975 This is part of the refactoring happening in bug 30975 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30975 [Bug 30975] Framework plugins do not work on cloned fields/subfields -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 32853] New: Fix cataloguing/value_builder/unimarc_field_125.pl
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32853 Bug ID: 32853 Summary: Fix cataloguing/value_builder/unimarc_field_125.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: trivial Priority: P5 - low Component: Cataloging Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Blocks: 30975 This is part of the refactoring happening in bug 30975 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30975 [Bug 30975] Framework plugins do not work on cloned fields/subfields -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 31051] New: Show patron's 'savings' on the OPAC
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31051 Bug ID: 31051 Summary: Show patron's 'savings' on the OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org It would be cool to have a feature which would show patrons via the OPAC how much they've saved by using the library, instead of purchasing items themselves. -- You are receiving this mail because: You are watching all bug changes.

1 74

[Bug 34908] New: Sort item types alphabetically by description rather than code when adding a new empty record as an order to a basket
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34908 Bug ID: 34908 Summary: Sort item types alphabetically by description rather than code when adding a new empty record as an order to a basket 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Item types are sorted by the code rather than the description in the Item type dropdown that is used when adding a new empty record as an order to a basket. To reproduce: 1. Go to Koha administration -> Item types. Add a new item type "B" with the description "Test" so it will be obvious if it is sorted by the code "B" instead of the description "Test". 2. Go to Acquisitions. Add to a basket from a new empty record 3. In the Catalog details section, note the Item type dropdown. Confirm your "Test" item type, is showing near the top of the list, indicating it has been sorted based on the code "B" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 34731] New: C4::Letters::SendQueuedMessages can be triggered with an undef message_id
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34731 Bug ID: 34731 Summary: C4::Letters::SendQueuedMessages can be triggered with an undef message_id Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org I've discovered that sometimes C4::Letters::EnqueueLetter will return undef instead of a valid message id. In Koha::Patron::set_password we call C4::Letters::EnqueueLetter and assume a message_id exists which we pass to C4::Letters::SendQueuedMessages. Because message_id is undef, we then *process all pending messages*. This is very very bad considering libraries often have very specific time frames they wish to send message ( especially sms and phone ). In addition, this bypasses the before_send_messages hook. I have not been able to recreate on demand yet, but I think it is either random or caused by calls to the /api/v1/patrons/<patron_id>/password rest api endpoint. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34