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

[Bug 40275] New: Add Koha::Patrons->find_by_identifier()
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40275 Bug ID: 40275 Summary: Add Koha::Patrons->find_by_identifier() Change sponsored?: --- Product: Koha Version: Main 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org As suggested by Frido in some other context, I file this bug to introduce the mentioned sub. I resurrected the idea after tracking down some warnings in SIP, and identifying bug 36575 introduced them by calling `->find` without passing a primary key. This kind of errors/warns: ``` [2025/06/30 13:03:23] [24253] [ERROR] [undef]@[undef]: DBIx::Class::ResultSource::_minimal_valueset_satisfying_constraint(): Unable to satisfy requested constraint 'primary', missing values for column(s): 'borrowernumber' at /kohadevbox/koha/Koha/Objects.pm line 98 C4::SIP::Trapper::__ANON__ /kohadevbox/koha/C4/SIP/Trapper.pm (70) ``` Instead of solving it locally, I propose to introduce a sane and tested method, and reuse it anywhere this pattern is being used. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46

[Bug 42041] New: CatalogModuleRelink disregards ConsiderHeadingUse
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42041 Bug ID: 42041 Summary: CatalogModuleRelink disregards ConsiderHeadingUse Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl CatalogModuleRelink will link authorities that were previously linked regardless if ConsiderHeadingUse is enabled or not. This is perhaps working as it should. However, if a library decided they do want to enable ConsiderHeadingUse in order to clean up inappropriately linked headings, CatalogModuleRelink will interfere. To replicate: 1. Check system preferences and ensure ConsiderHeadingUse is set to don't, AutoLinkBiblios is set to do, CatalogModuleRelink is set to do. 2. Import an authority that is not currently in use, such as a subject authority for $a Application software $xDevelopment. 3. Edit a bibliographic record and add a heading to match the authority. 4. Save. See the authority links to the heading. 5. Change the system preference ConsiderHeadingUse to Do. Leave the remaining system preferences as previously set. 6. Refresh the page for the bibliographic record. See the heading relinks to the authority. 7. Delete the heading and save the record. 8. Edit the authority and change 008/15 to not appropriate. 9. Edit the bibliographic record and add the heading back and save. See that the heading re-links to the authority because it was previously linked. 10. Delete the heading in the bibliographic record and save. 11. Change the system preference CatalogModuleRelink to don't. 12. Edit the bibliographic record and add the heading back. Save. See the heading does not relink/link because the authority says it is not appropriate as a subject heading. 13. Edit the authority and update 008/15 to appropriate. 14. Edit the record and save. See the heading now links. >From what I can see, Koha is working the way it should based on the system preferences. Since CatalogModuleRelink might interfere with ConsiderHeadingUse, what should happen in an existing catalog in regards to linking? Should the recommendation be to disable CatalogModuleRelink when ConsiderHeadingUse is set to do? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 28761] New: Item status shows incorrectly on opac-course-details.pl
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28761 Bug ID: 28761 Summary: Item status shows incorrectly on opac-course-details.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: - create a course in course reserves, add an item to it. - confirm your item shows Available for its status on opac-course-details.pl - give your item a notforloan status - reload opac-course-details.pl, confirm its still "available" - give your item a restricted user status - reload opac-course-details.pl, confirm its still "available" - give your item a lost, damaged, or withdrawn status - reload opac-course-details.pl, these statuses *are* reflected Filing a separate bug for the staff client. -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 38804] New: erm : JSTOR usage data not harvestable via SUSHI
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38804 Bug ID: 38804 Summary: erm : JSTOR usage data not harvestable via SUSHI Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Trying to harvest JSTOR usage data via SUSHI returns an error in Koha job : "SUSHI returned: Warning - Report Queued for Processing 1011" This behavior is documented in Counter registry (https://registry.countermetrics.org/platform/335608df-e4d2-46ad-bd89-fb3683…) for JSTOR "The same report cannot be requested more than 5 times per day. JSTOR uses reporting queuing so if data is not yet available, clients will need to re-request the report at a later date." and in JSTOR site : https://support.jstor.org/hc/en-us/articles/360015483214-SUSHI-reports-COUN… "Please wait at least one (1) hour between report requests to allow time for report files to be generated." I suppose other data provider may have the same policy. For Koha to be able to harvest them, it should be necessary to add an option to relaunch the harvesting process after a parametrable delay -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 42029] New: Add diff support to RECALLS action logs
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42029 Bug ID: 42029 Summary: Add diff support to RECALLS action logs Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Blocks: 37940 The action logging for the RECALLS module (Koha/Recall.pm) currently logs status-change actions (OVERDUE, EXPIRE, CANCEL, FILL) with simple string messages such as 'Recall status set to overdue'. These calls do not pass the $original parameter to logaction(), so no structured diff is generated in the action_logs.diff column. This bug covers updating the four logaction() calls in Koha/Recall.pm to pass the pre-change recall state as the sixth argument ($original), enabling before/after comparison in the action log viewer. Affected calls: - RECALLS/OVERDUE (Koha/Recall.pm ~line 437) - RECALLS/EXPIRE (Koha/Recall.pm ~line 454) - RECALLS/CANCEL (Koha/Recall.pm ~line 470) - RECALLS/FILL (Koha/Recall.pm ~line 486) Since Koha::Recall is a Koha::Object subclass, $self->unblessed can be captured before the status change and passed as $original. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37940 [Bug 37940] [OMNIBUS] All modification logged via action logs should include original to create JSON diff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42028] New: DB backup improvements: use ZSTD compression and tweak default settings
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42028 Bug ID: 42028 Summary: DB backup improvements: use ZSTD compression and tweak default settings Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: schodkowy.omegi-0r(a)icloud.com Reporter: schodkowy.omegi-0r(a)icloud.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 42011] New: Unused arguments in members/readingrec.pl
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42011 Bug ID: 42011 Summary: Unused arguments in members/readingrec.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com In members/readingrec.pl: 112 my $oc = $patron->old_checkouts( 113 {}, 114 { 115 order_by => 'date_due desc', 116 prefetch => { item => { biblio => 'biblioitems' } }, 117 } 118 )->as_list; old_checkout does not take any argument, is a ->search missing ? order_by syntax looks obsolete too https://metacpan.org/pod/DBIx::Class::ResultSet#order_by -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 42027] New: Implement "Show volumes" for serial records
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42027 Bug ID: 42027 Summary: Implement "Show volumes" for serial records Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: pascal.uphaus(a)gwdg.de Currently Koha can show the "Show volumes" link for set and traced series records. With a search in the background we check for existing volumes and display of the link depends on their existence. The same should be implemented for serial records that can also have separate records in some libraries for bound volumes of serial issues. Currently we use this XSLT to always show the link for serial records (or never, depending on CSS): <xsl:template name="serial_volumes"> <xsl:param name="gui"/> <xsl:param name="UseControlNumber" /> <xsl:variable name="SearchUrl"> <xsl:call-template name="SearchUrl"> <xsl:with-param name="gui"><xsl:value-of select="$gui" /></xsl:with-param> </xsl:call-template> </xsl:variable> <xsl:if test="substring(marc:leader,8,1) = 's' and not(substring(marc:leader,20,1)='a' or substring(marc:controlfield[@tag=008],22,1)='m')"> Volumes: Bände: <a> <xsl:choose> <xsl:when test="$UseControlNumber = '1' and marc:controlfield[@tag=001]"> <xsl:attribute name="href"><xsl:value-of select="$SearchUrl"/>q=rcn:<xsl:value-of select="marc:controlfield[@tag=001]"/>+not+(bib-level:a+or+bib-level:b)</xsl:attribute> </xsl:when> <xsl:otherwise> <xsl:attribute name="href"><xsl:value-of select="$SearchUrl"/>q=ti,phr:<xsl:value-of select="translate(marc:datafield[@tag=245]/marc:subfield[@code='a'], '/', '')"/></xsl:attribute> </xsl:otherwise> </xsl:choose> Show volumesZeige Bände </a> </xsl:if> </xsl:template> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 30533] New: Add exact search option for patrons
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30533 Bug ID: 30533 Summary: Add exact search option for patrons 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com A patron search for names like "JOHN JOHNSON" ends up getting parsed something like "WHERE surname like "%JOHN%" OR firstname like "%JOHN%" OR surname like "%JOHNSON%" OR firstname like "%JOHNSON%"" and finds a really unhelpfully large pile of patrons. Bug 17500 suggests implementing Elastic for patron searching, which would be great. In the meantime, we could give a little help for searches like this by giving an exact search option -- so the query would parse more or less the same but without the wildcards. That's also a problematic search for many situations, but would work better here. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 42026] New: Add fallback label text when ind. 2 is empty for 264
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42026 Bug ID: 42026 Summary: Add fallback label text when ind. 2 is empty for 264 Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: pascal.uphaus(a)gwdg.de Currently, when 264 ind. 2 is left empty, Koha won't show a label for the field in the OPAC. As quality of records might vary, it would be good to add a fallback to the XSLT that covers unknown and empty ind. 2 values. https://git.koha-community.org/Koha-community/Koha/src/commit/e7855c0c016e2… -- You are receiving this mail because: You are watching all bug changes.

1 2