May 2026 - Koha-bugs - lists.koha-community.org

[Bug 41639] New: OPAC cover images use non-descriptive alt text
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '26

11 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41639 Bug ID: 41639 Summary: OPAC cover images use non-descriptive alt text Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: accessibility Severity: normal Priority: P5 - low Component: Accessibility Assignee: Laura.escamilla(a)bywatersolutions.com Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, oleonard(a)myacpl.org Cover images displayed in the Koha OPAC currently use generic alt text values such as “Amazon Cover Image” and “Local Cover Image.” These values do not provide a meaningful text alternative for screen reader users and do not meet WCAG 2.2 AA Success Criterion 1.1.1 (Non-text Content). Because OPAC cover images are functional (they are clickable and serve as a visual identifier for bibliographic records), they cannot be considered decorative and therefore require a descriptive text alternative. -- You are receiving this mail because: You are watching all bug changes.

1 33

[Bug 42221] New: autoarcode set to incremental EAN-13 barcodes do not increment
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '26

11 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42221 Bug ID: 42221 Summary: autoarcode set to incremental EAN-13 barcodes do not increment Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging 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: m.de.rooy(a)rijksmuseum.nl I don't know if this is the same as bug 41765, because Pavel says they increment in 7s but mine don't increment at all. I found this on 25.05 and confirmed it's still the case on main. To recreate : 1. Change the autobarcode system preference to incremental EAN-13 barcodes 1.1. Go to Administration > System preferences 1.2. Search for autobarcode -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 27507] New: Search host record using control number identifier / organization code
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '26

11 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27507 Bug ID: 27507 Summary: Search host record using control number identifier / organization code 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: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 11175 In /cgi-bin/koha/catalogue/detail.pl currently if you are viewing a record with 773w field the page shows "In: XXXX" with a search link to the host record. Currently when the 773w field format is in the LOC format of (OrgCode)ControlNumber we only search using the ControlNumber part. When importing records to Koha from different databases it is necessary to search also using the organization's code that is in the parentheses – otherwise we get in the results also unrelated records from other organizations. We need the 003 / Control-number-identifier search addition from bug 11175 to implement this. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11175 [Bug 11175] Show the parent record's component parts in the detailed views -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 29268] New: Query used in Koha::Biblio->get_marc_host is incorrect
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '26

11 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29268 Bug ID: 29268 Summary: Query used in Koha::Biblio->get_marc_host is incorrect 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 After digging through this some more in relation to bug 27507 and bug 11175 I have come to the conclusion that I think the searches performed by get_marc_host are too simplistic/incorrect. First of all, both the 773 field and $w subfield are repeatable.. so we need to iterate for subfields as well as the field. Secondly, I don't think the search for (RCI)CN is correct.. this is what would appear in the 773 of the child, not how the 001 would be constructed in the host. What I believe we really need to do is as follows: 1. Iterate through 773 fields. 2. Iterate through subfield w's and looks for one of the following: 1a. (RCI)Controlnumber where the RCI matches the OrgCode syspref 1b. Fully numeric Controlnumber 3. Once we've found the form we're expecting from above iterations (1a in preference to 1b if both exist) jump out of the loops. 3. Produce the search string 'control-number=Controlnumber' for 1b. or `control-number=Controlnumber AND rci=RCI` if 1a is found. It may also be helpful to add the `OR control-number=Controlnumber` search to 1a to account for cases where OrgCode was added to new children but was is missing from the host? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 42331] New: Data corruption in CSV reports
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '26

11 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42331 Bug ID: 42331 Summary: Data corruption in CSV reports Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com In CSV export of SQL reports, even if the content is not HTML, the characters < and > are converted into HTML entities (< and >), which breaks the reading of the CSV with usual tools if the semicolon (;) is used as a delimiter It seems it is caused by https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5920 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 33350] New: Show items info several times in notice content
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '26

11 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33350 Bug ID: 33350 Summary: Show items info several times in notice content 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: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org In Notices such as Overdue notice (ODUE) you may want to show more than once the info of the overdue items. <item>"<<biblio.title>>" by <<biblio.author>>, <<items.itemcallnumber>>, Barcode: <<items.barcode>> Fine: <<items.fine>></item> Some clients may want to have the info in several languages in the same notice, instead of having a different notice for every language. Right now, if you put <item></item> more than once, it doesn't work properly, as the function GetPreparedLetter (C4/Letters.pm) does the following. Example <item>"<<biblio.title>>" by <<biblio.author>>, <<items.itemcallnumber>>, Barcode: <<items.barcode>> Fine: <<items.fine>></item> <item>"<<biblio.title>>" de <<biblio.author>>, <<items.itemcallnumber>>, Código de barras: <<items.barcode>> Sanción: <<items.fine>></item> It picks everything from the first <item> to the last </item> and replaces <<items.>> with their values. "<<biblio.title>>" by <<biblio.author>>, <<items.itemcallnumber>>, Barcode: <<items.barcode>> Fine: <<items.fine>></item> <item>"<<biblio.title>>" de <<biblio.author>>, <<items.itemcallnumber>>, Código de barras: <<items.barcode>> Sanción: <<items.fine>> The result is a mess that looks like this: The following item(s) is/are currently overdue: "Sucker punch " by Hamilton, Laurell K., , Barcode: CPL22090005 Fine: $0.00 Los siguientes ejemplares tienen retrasos: "Sucker punch " de Hamilton, Laurell K., , Código de barras: CPL22090005 Multa: $0.00 "Legion of Super-Heroes" by Levitz, Paul, , Barcode: CPL23010002 Fine: $0.00 Los siguientes ejemplares tienen retrasos: "Legion of Super-Heroes" de Levitz, Paul, , Código de barras: CPL23010002 Multa: $0.00 It should pick the content between the first <item> and the first </item>, and then the same with the second pair, the third pair and so on. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 21472] New: Links in Additional Formats section of bib details do not work
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '26

11 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21472 Bug ID: 21472 Summary: Links in Additional Formats section of bib details do not work Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul(a)flo.org QA Contact: testopia(a)bugs.koha-community.org The links that appear under the heading Additional Formats, built using data from 776 fields, are hardcoded to be like this in the OPAC: /cgi-bin/koha/opac-search.pl?q=control-number:__________ And like this in the staff interface: /cgi-bin/koha/catalogue/search.pl?q=control-number:__________ The blanks are filled in with the contents of the 776 field, subfield $w, with any parenthesized organization code stripped. Thus, for example, a 776 field like this: 776 08 $i Online version: [...] $z 9781938168000 $w (OCoLC)895896190 Would yield a staff URL like this: /cgi-bin/koha/opac-search.pl?q=control-number:895896190 But that link won't work, at least not in our case; control numbers found in 035 $a are indexed as other-control-number, not control-number, and the organization code is not stripped when indexing. However, a link like this does retrieve the bib record with the 776 field given above: /cgi-bin/koha/catalogue/search.pl?idx=other-control-number,phr&q=(OCoLC)895896190 These links are built in /usr/share/koha/opac/htdocs/opac-tmpl/bootstrap/en/xslt/MARC21slim2OPACDetail.xsl (lines 808 ff.) and /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/xslt/MARC21slim2intranetDetail.xsl (lines 756 ff.); for example, the latter looks like this:  <xsl:if test="marc:datafield[@tag=776]"> <span class="results_summary add_physical_form"> <span class="label">Additional physical formats: </span> <xsl:for-each select="marc:datafield[@tag=776]"> <xsl:variable name="linktext"> <xsl:choose> <xsl:when test="marc:subfield[@code='t']"> <xsl:value-of select="marc:subfield[@code='t']"/> </xsl:when> <xsl:when test="marc:subfield[@code='a']"> <xsl:value-of select="marc:subfield[@code='a']"/> </xsl:when> <xsl:otherwise> <xsl:text>No title</xsl:text> </xsl:otherwise> </xsl:choose> </xsl:variable> <xsl:if test="@ind2=8 and marc:subfield[@code='i']"> <xsl:call-template name="subfieldSelect"> <xsl:with-param name="codes">i</xsl:with-param> </xsl:call-template> <xsl:text>: </xsl:text> </xsl:if> <xsl:choose> <xsl:when test="marc:subfield[@code='w']"> <a> <xsl:attribute name="href"> <xsl:text>/cgi-bin/koha/catalogue/search.pl?q=control-number:</xsl:text> <xsl:call-template name="extractControlNumber"> <xsl:with-param name="subfieldW"> <xsl:value-of select="marc:subfield[@code='w']"/> </xsl:with-param> </xsl:call-template> </xsl:attribute> <xsl:value-of select="$linktext"/> </a> </xsl:when> <xsl:otherwise> <xsl:value-of select="$linktext"/> </xsl:otherwise> </xsl:choose> <xsl:if test="position() != last()"> <xsl:text>; </xsl:text> </xsl:if> </xsl:for-each> </span> </xsl:if> The template "extractControlNumber" extracts the control number (minus parenthesized prefix) from the value in 776 $w. Unfortunately, this template is used elsewhere so I'm not sure it's safe to change it so that it does *not* strip the parenthesized prefix. Perhaps we could add a second parameter to it that specifies whether or not to strip it, with the default set to true. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 22439] New: Duplicated code in PrepHostMarcField and prepare_host_field
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '26

11 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22439 Bug ID: 22439 Summary: Duplicated code in PrepHostMarcField and prepare_host_field 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: pasi.kallinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- The C4/Biblio.pm subroutines PrepHostMarcField and prepare_host_field both do the same thing, so should be merged. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 70

[Bug 35117] New: get_marc_components and get_marc_volumes should be more consistent
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '26

11 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35117 Bug ID: 35117 Summary: get_marc_components and get_marc_volumes should be more consistent 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: 35099 Bug 35099 highlighted a number of inconsistencies between these two parallel methods.. we should bring them closer. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35099 [Bug 35099] Cannot load records with invalid marcxml -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 35330] New: Split rcn index to allow for more specific searches
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '26

11 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35330 Bug ID: 35330 Summary: Split rcn index to allow for more specific searches Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 26314 At the moment the index on Record control-number (7xx$w, 8xx$w) includes the $w subfields of multiple linking fields. This means that we can't specify a search that only find a specific type of link. Example: * Finding all volumes linked to a set record, will also find records that are also linked as another physical form (776) or a preceding entry (780) It would be nice to have the general, but also more specific indexes limited to the relevant $w only. As features like bug 26314 use the indexes in internal functions to do searches in the background, we cannot easily solve this with local changes to indexing and XSLT. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26314 [Bug 26314] "Volumes: show volumes" showing regardless of whether there are volumes linked to the record -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6