June 2021 - Koha-bugs - lists.koha-community.org

[Bug 23296] New: Auto Renewal Notice does not use Library specific notices
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23296 Bug ID: 23296 Summary: Auto Renewal Notice does not use Library specific notices Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org All notices in Koha are created to be a default ALL libraries notice, however, with branch systems, there is also the ability to create a library specific notice that can be used instead. However, the notice AUTO_RENEWALS is not currently capable of being library specific - instead, the ALL Library Notice for AUTO_RENEWALS is the only one that Koha send. To adjust this, it would be recommended that a library specific notice like all the others in Koha can be created. Following circ control, would be the suggested way to go as with most notices in Koha. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 25539] New: Remove AddBiblio "defer_marc_save" option
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25539 Bug ID: 25539 Summary: Remove AddBiblio "defer_marc_save" option Change sponsored?: --- Product: Koha Version: unspecified 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: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org In bulkmarcimoprt.pl AddBiblio is called with defer_marc_save => 1. This perhaps made sense sometime when items where saved embedded with the MARCXML, but since that is no longer the case(?) there is no need for saving the MARC-data once more after processing items in bulkmarcimport.pl. Thus this option can/should be removed. The current behavior actually blocks bug 14957, we recently discovered, since calling ModBiblioMarc after the record has been saved bypasses marc merge rules on updates (which are applied in ModBiblio) and that save will ignore the possible rules that has been setup. I also discovered some other odd things that will not address in this bug. One of the being that since ModBiblio runs _strip_item_fields no items will ever be imported though bulkmarcimport on updates (but will be in inserts). I'm pretty sure this is the case (have tested and verified, but seems odd this kind of bug has survived undetected for so long). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 106

[Bug 22780] New: MarkLostItemsAsReturned - map to Lost-sttaus instead of context where the transaction took place
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22780 Bug ID: 22780 Summary: MarkLostItemsAsReturned - map to Lost-sttaus instead of context where the transaction took place Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: klas.blomberg(a)skovde.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- Syspref MarkLostItemsAsReturned is mapped to the context where you make the transaction - Holds to pull list, longoverdue cronjob et.c. I can't see any logical reason for this! I think it would be better to map to Lost-statuses: Lost = don't mark as returned Longoverdue = don't mark as returned Lost and paid for = mark as returned et.c. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 25520] New: Change wording on SMS phone number set up
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25520 Bug ID: 25520 Summary: Change wording on SMS phone number set up 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: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The wording in the staff interface when a staff member is adding an SMS number is confusing. Could we show two different formats to enter a phone number? For example: SMS number should be in the format 9876543210 or +11234567890 On the OPAC, I believe it looks clearer to users: Please enter numbers only. (123) 456-7890 would be entered as 1234567890. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 24424] New: Advanced editor - interface hangs as "Loading" when given an invalid bib number
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24424 Bug ID: 24424 Summary: Advanced editor - interface hangs as "Loading" when given an invalid bib number 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: carnold(a)dgiinc.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The Advanced Editor hangs with "Loading, please wait" message when given an invalid bib number /cgi-bin/koha/cataloguing/editor.pl#catalog/55555 https://paste.pics/e7c7e4956dfa888b13b54332472df066 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 27198] New: Sync marc21-retrieval-info-auth-dom.xml with retrieval-info-auth-dom.xml
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198 Bug ID: 27198 Summary: Sync marc21-retrieval-info-auth-dom.xml with retrieval-info-auth-dom.xml Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au ./debian/templates/marc21-retrieval-info-auth-dom.xml is out-dated and should be synchronized with ./etc/zebradb/retrieval-info-auth-dom.xml The main issue is that the XML retrieval syntax is wrong which prevents a person from using the Zebra special retrieval elements documented at https://software.indexdata.com/zebra/doc/special-retrieval.html -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 25835] New: Include Overdue Report (under Circulation Module) as a Staff Permission
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25835 Bug ID: 25835 Summary: Include Overdue Report (under Circulation Module) as a Staff Permission Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently, when setting up permission for staff, the report for Overdue reports portion of the Circulation module, is only partially included in staff permission. There is a permission that allows staff to run the Overdue report )Execute overdue items report (overdues_report)) - but this does prohibit the Overdue report from displaying on circulation page, but the Overdue with Fines does display. It would more helpful, if this permission included both reports or add another permission to allow libraries to include/exclude this other report. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 28012] New: Error on Saving new numbering pattern
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28012 Bug ID: 28012 Summary: Error on Saving new numbering pattern Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: christian.stelzenmueller(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org I got an error after klicking on the Save button for saving a new numbering pattern. 1. go to the serials module 2. click on manage numbering patterns in the left hand navigation 3. add a pattern 4. Fill in the fields 5. Filling in the Numbering formula field leads to an error after saving. Leaving the numbering formula field blank, no error occurs, but the new pattern won't be saved it seems First lines of error trace: C4::Serials::Numberpattern::AddSubscriptionNumberpattern(): DBI Exception: DBD::mysql::st execute failed: Incorrect integer value: '' for column `koha_christian8`.`subscription_numberpatterns`.`displayorder` at row 1 [for Statement "INSERT INTO subscription_numberpatterns(label,description,numberingmethod,displayorder,label1,label2,label3,add1,add2,add3,every1,every2,every3,setto1,setto2,setto3,whenmorethan1,whenmorethan2,whenmorethan3,numbering1,numbering2,numbering3) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)" with ParamValues: 0="blablub", 1="blablubdescription", 2="{X}, H. {Y} {Z} ", 3="", 4="Jahr", 5="Jahrgang", 6="Heft", 7="1", 8="1", 9="1", 10="12", 11="6", 12="1", 13="1", 14="1", 15="1", 16="9999", 17="9999", 18="6", 19="", 20="", 21=""] at /kohadevbox/koha/serials/subscription-numberpatterns.pl line 62 at /usr/share/perl5/DBIx/Class/Exception.pm line 77 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 45

[Bug 17258] New: [OMIBUS] MySQL 5.7
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17258 Bug ID: 17258 Summary: [OMIBUS] MySQL 5.7 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org This is an omnibus report to group the different issues under MySQL 5.7 -- You are receiving this mail because: You are watching all bug changes.

1 136

[Bug 27153] New: ElasticSearch should search keywords apostrophe blind
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27153 Bug ID: 27153 Summary: ElasticSearch should search keywords apostrophe blind Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.field(a)ptfs-europe.com We are often asked why keyword searches don't ignore apostrophes. If you searched for "carries war" on Google, the first hits that come up are for Carrie's War by Nina Bawden. If you do a keyword search in Koha for "carries war" you get 0 hits. If you search for "carrie's war" you will find copies of this book. Koha with ElasticSearch should search apostrophe-blind (ignore the apostrophe). This was a perennial problem with zebra. In zebra you had to change words-icu.xml to ignore apostrophes. We should deliver an ES index_config.yaml that handles this scenario. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 81