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

[Bug 34663] New: Unimarc Default framework
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34663 Bug ID: 34663 Summary: Unimarc Default framework 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: Igor.A.Sychev(a)mail.ru QA Contact: testopia(a)bugs.koha-community.org New install Koha 23.05.02 Please correct in the Unimarc Default framework. subfields not in same tabs Not all subfields for the following tags are in the same tab (or marked 'ignored'). Code Description Tag Tabs in use Default framework 410 3,4 Default framework 411 3,4 Default framework 412 3,4 Default framework 413 3,4 Default framework 421 3,4 Default framework 422 3,4 Default framework 423 3,4 Default framework 424 3,4 Default framework 425 3,4 Default framework 430 3,4 Default framework 431 3,4 Default framework 432 3,4 Default framework 433 3,4 Default framework 434 3,4 Default framework 435 3,4 Default framework 436 3,4 Default framework 437 3,4 Default framework 440 3,4 Default framework 441 3,4 Default framework 442 3,4 Default framework 443 3,4 Default framework 444 3,4 Default framework 445 3,4 Default framework 446 3,4 Default framework 447 3,4 Default framework 448 3,4 Default framework 451 3,4 Default framework 452 3,4 Default framework 453 3,4 Default framework 454 3,4 Default framework 455 3,4 Default framework 456 3,4 Default framework 461 3,4 Default framework 462 3,4 Default framework 463 3,4 Default framework 464 3,4 Default framework 470 3,4 Default framework 481 3,4 Default framework 482 3,4 Default framework 488 3,4 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 29522] New: Bib record not correctly updated when merging identical authorities with LinkerModule set to First Match
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29522 Bug ID: 29522 Summary: Bib record not correctly updated when merging identical authorities with LinkerModule set to First Match Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: normal 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 To recreate: 1 - have LinkerModule set to First Match 2 - have a bib with its author linked to an authority 3 - duplicate that authority, confirm that an authority search for your author brings up two identical authorities, one linked to your bib 4 - merge the two authority records, telling Koha to keep the newer of the two (the one not linked to your bib) 5 - search authorities for your author again, confirm you see just one authority and it's not linked to any bibs 6 - reload your bib, see the 100$9 contains the number for the authority you deleted in the merge 7 - edit your bib to correctly link it to the remaining authority 8 - set LinkerModule to Default 9 - repeat steps 3 and 4 10 - see your remaining authority is linked to your bib, the bib has the correct authority number I'm not able to replicate this in master. I'm not sure what changed from 21.05. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 37

[Bug 35125] New: AutoCreateAuthorities creates separate authorities when thesaurus differs, even with LinkerConsiderThesaurus set to Don't
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35125 Bug ID: 35125 Summary: AutoCreateAuthorities creates separate authorities when thesaurus differs, even with LinkerConsiderThesaurus set to Don't Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl, nick(a)bywatersolutions.com Setup: * Set AutoCreateAuthorities to generate, AutoLinkBiblios to Do, CatalogModuleRelink to Do (and EnableAdvancedCatalogingEditor to enable if you want to make your life easier) * Ensure that LinkerConsiderThesaurus is at the default Don't * Make sure you don't have a genre authority record for Boring stories Add the following headings to a bib record and save it 655 _ _ ‡aBoring stories 655 _ 0 ‡aBoring stories 655 _ 4 ‡aBoring stories 655 _ 7 ‡aBoring stories‡2gsafd 655 _ 7 ‡aBoring stories‡2lcgft Note that you now have each heading linked to a different authid, and you have five genre authority records for Boring stories, all identical. If instead you already had a Boring stories authority record (no matter the thesaurus) before saving the record, they would have all been linked to it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[Bug 29087] New: Holds to pull list can crash with a SQL::Abstract puke
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29087 Bug ID: 29087 Summary: Holds to pull list can crash with a SQL::Abstract puke 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: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Opening the holds to pull list page can crash with the following logged error: SQL::Abstract::puke(): [SQL::Abstract::__ANON__] Fatal: SQL::Abstract before v1.75 used to generate incorrect SQL when the -NOT IN operator was given an undef-containing list: !!!AUDIT YOUR CODE AND DATA!!! (the upcoming Data::Query-based version of SQL::Abstract will emit the logically correct SQL instead of raising this exception) at /usr/share/koha/lib/Koha/Objects.pm line 145 I've traced this to Koha::Holds->get_items_that_can_fill(). Among other things, this routine fetches a list of item types that cannot fill holds, i.e., cases where the 'holdallowed' rule value is 'not_allowed'. However, if your default rule is to not allow holds, the @hold_not_allowed_itypes list will end up including an entry whose value is undef. When passed to the item query, doing the -not_in filter on itype will result in the crash listed above. A quick fix might be to filter out undef from that list. That will fix the crash, but could lead to incorrect results if the default policy is to deny holds for all item types except for ones that are going to be specifically permitted. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 56

[Bug 33237] New: If TranslateNotices is off, use the interface language includes in slips
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33237 Bug ID: 33237 Summary: If TranslateNotices is off, use the interface language includes in slips Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Most of our clients use Koha in one language only (French) and their patrons are also all french-speakers. So they don't use TranslateNotices, since they don't need to print slips in different languages. However, if TranslateNotices is off, the translations for "includes" (in my specific example, account types), are not taken into consideration and print in English. Same if TranslateNotices is on, but the patron's language is Default. In those cases, shouldn't it use the interface language rather than just print in English? To replicate: 1. Install the other language (i used fr-CA here) 1.1. gulp po:update fr-CA ./misc/translator/translate install fr-CA 1.2. In Administration > Global system preferences, search for language and check the added language 2. Create a manual invoice in a patron's account and pay it 3. From the Transactions tab, click 'Print' next to the payment line --> On the printed slip, the title is "Payment receipt" (OK) 4. Switch interface to other language 5. Redo step 3 --> On the printed slip, the title is still "Payment receipt" (not ok) 6. In Administration > Global system preferences, enable TranslateNotices 7. Go to Tools > Notices and slips > ACCOUNT_CREDIT and copy the content of the letter into all the languages 8. Redo step 3 (you should still be in the other language interface) --> On the printed slip, the title is still "Payment receipt" (not ok?) 9. Edit the patron's account and change the preferred language to the other language 10. Redo step 3 --> On the printed slip, the title is "Paiement receipt" (OK) On step 3, the account type is in English in the English interface (OK) On step 5, the account type is in English in the other interface, with TranslateNotices off, I feel like the slip should take the interface into account in this case for the include... On step 8, TranslateNotices is on, but the patron's language is Default, I feel like this should also take into account the interface language... On step 10, TranslateNotices is on and patron language is set, these are currently the only settings which allow to have the accounttypes in the other language. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 90

[Bug 34972] New: Canceling a waiting hold from the holds over tab can make the next hold unfillable
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34972 Bug ID: 34972 Summary: Canceling a waiting hold from the holds over tab can make the next hold unfillable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major 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 When a staff member cancels a hold by clicking the button in the "holds waiting over 10 days" report, Koha incompletely attempts to assign that item to the next matching hold. Koha assigns the itemnumber to the hold, but does *not* set found status of the hold. Instead, it prompts the staff member, "Please retain this item and check it in to process the hold." This causes a few problems: - The itemnumber is immediately assigned to the hold without an opportunity for staff input, even if HoldsAutoFill is disabled. - If the staff member does not check in the book afterward (whether intentionally or through human error), it leaves the hold in an invalid state: it is tied to the itemnumber, but it is neither "found" nor an item-level hold. - Since the itemnumber is assigned, other items can't fill the hold. However, since the "found" field was never set, the option to "revert waiting status" or "revert transit status" isn't available. Essentially, a bib-level hold is suddenly behaving like an item-level hold, with no way for staff to identify or fix the issue. This is especially a problem if the item is missing from the holds shelf for some reason, and the staff member cancels the waiting hold first and then marks the item "lost". This makes the next-in-line hold unfillable unless the item is found. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 52

[Bug 33832] New: Can't change a patron's username without entering passwords
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33832 Bug ID: 33832 Summary: Can't change a patron's username without entering passwords Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In the staff interface, on the "Change password" page, it's not possible to update a patron's username without also entering password information. This is contrary to the help text, "Leave the field blank to leave password unchanged." As far as I can tell this bug goes back to at least 21.05.x -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 34647] New: name attribute is obsolete in anchor tag
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34647 Bug ID: 34647 Summary: name attribute is obsolete in anchor tag Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Accessibility Assignee: martin.renvoize(a)ptfs-europe.com Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, oleonard(a)myacpl.org Looks like since HTML5, attribute "name" on tag <a> is obsolete : https://html.spec.whatwg.org/multipage/obsolete.html#obsolete-but-conformin… We have a few of them : koha-tmpl/intranet-tmpl/prog/en/modules/acqui/booksellers.tt: <a name="[% supplier.booksellerid | html %]" href="/cgi-bin/koha/acqui/supplier.pl?booksellerid=[% supplier.booksellerid | uri %]"> koha-tmpl/intranet-tmpl/prog/en/modules/acqui/booksellers.tt: <a name="[% supplier.booksellerid | html %]" href="/cgi-bin/koha/acqui/supplier.pl?booksellerid=[% supplier.booksellerid | uri %]"></a> koha-tmpl/intranet-tmpl/prog/en/modules/admin/smart-rules.tt: <a name="viewnote" data-toggle="popover" title="Note" data-content="[% note | html %]" data-placement="top" data-trigger="hover">View note</a> koha-tmpl/intranet-tmpl/prog/en/modules/reports/catalogue_out.tt: <h3><a name="summary" id="summary"></a>Summary</h3> koha-tmpl/intranet-tmpl/prog/en/modules/tools/marc_modification_templates.tt: <a name="modaction"></a> koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-main.tt: <a name="newsitem[% koha_new.idnew | html %]" href="/cgi-bin/koha/opac-main.pl?news_id=[% koha_new.idnew | uri %]">[% koha_new.title | html %]</a> koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-memberentry.tt: [% IF loop.first %]<a name="patron-attr-start-[% pa.type.code | html %]"></a>[% END %] How should we replace ? Some may be not uniq so can't be an id. Maybe an accessibility issue. -- You are receiving this mail because: You are watching all bug changes.

1 31

[Bug 31143] New: We should attempt to fix/identify all cases where '0000-00-00' may still remain in the database
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31143 Bug ID: 31143 Summary: We should attempt to fix/identify all cases where '0000-00-00' may still remain in the database Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org With the move to more and more of Koha using the REST API's and our rest API's being suitably strict about date formats, we need to retrospectively correct occurrences of 0000-00-00 dates appear in database fields system wide. I've had enough occurrences of bad data still in the database after a number of upgrade and it biting me in the UI that I think we should now look at introducing a script to either bulk fix these or at the least identify them and warn they will cause serious issues going forward. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 127

[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