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

[Bug 31070] New: [DOCS] Did you mean? section needs an update
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '26

11 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31070 Bug ID: 31070 Summary: [DOCS] Did you mean? section needs an update Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org The Did you mean? section in the administration chapter needs an update (https://koha-community.org/manual/22.05/en/html/administration.html#did-you…) Updates required include: - Updated screenshots - Remove important note about it only working in the OPAC - Add information about the LibrisSpellCheck plugin Related changes to the searching preferences page: - Punctuation and spelling - Link to administration > did you mean section Other changes: - Check whether any update to the OPAC page is required -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 37473] New: Circulation rule holdallowed set to not_allowed results in warning when browsing a biblio record
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '26

11 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37473 Bug ID: 37473 Summary: Circulation rule holdallowed set to not_allowed results in warning when browsing a biblio record Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Circulation rule holdallowed set to not_allowed results in warning when browsing a biblio record : > No method count found for Koha::Items > DBIx::Class::SQLMaker::ClassicExtensions::puke(): Fatal: NULL-within-IN not > implemented: The upcoming SQL::Abstract::Classic 2.0 will emit the logically > correct SQL instead of raising this exception. at /home/koha/src/bin/../Koha/ > Objects.pm line 587 from C4/items.pm > 64 my @hold_not_allowed_itypes = Koha::CirculationRules->search( > 65 { > 66 rule_name => 'holdallowed', > 67 branchcode => undef, > 68 categorycode => undef, > 69 rule_value => 'not_allowed', > 70 } > 71 )->get_column('itemtype'); This results in pushing undef in an array and searching "not in" in that array, which is forbidden. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

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

11 Nov '26

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 57

[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 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