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

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

10 Nov '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 6

[Bug 42386] New: Unify hold availability checks into Koha::Availability pattern
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '26

10 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42386 Bug ID: 42386 Summary: Unify hold availability checks into Koha::Availability pattern 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: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 41728, 42385 Hold availability is currently split across three different interfaces with different return shapes: - Koha::Patron->can_place_holds â patron eligibility gate Returns Koha::Result::Boolean with messages - C4::Reserves::CanItemBeReserved â item-level hold policy Returns hashref with {status} - C4::Reserves::CanBookBeReserved â biblio-level hold policy Returns hashref with {status} This bug proposes unifying these into the Koha::Availability pattern introduced in bug 41728: - Koha::Patron::Hold::Availability â patron eligibility checks (expired, debt, restricted, card lost, global hold limit) - Koha::Item::Hold::Availability â item-level hold policy checks (hold policy, circ rules, on-shelf holds, pickup location, etc.) Both would return Koha::Availability::Result and support no_short_circuit and overrides, consistent with the checkin availability class. This would also require untangling patron-level checks that leaked into CanItemBeReserved (e.g. maxreserves in certain code paths) and pushing them back to the patron-level orchestrator. Note: This is a significant refactoring effort. CanItemBeReserved has ~15 different checks with complex interactions. A multi-patch approach is recommended. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41728 [Bug 41728] Add `Koha::Item::Checkin::Availability` to centralize logic https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42385 [Bug 42385] Extract _GetCircControlBranch into Koha::Policy::Circulation -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 163

[Bug 34210] New: ISSUEQSLIP should offer checkout session items only
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '26

10 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34210 Bug ID: 34210 Summary: ISSUEQSLIP should offer checkout session items only 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Koha needs to have some mechanism in place to track items a patron checked out in a particular session (this information clears every time a new patron is loaded. Maybe linked to when the last patron button is updated). It would then be helpful in being creating some kind of mechanism so that ISSUEQSLIP could print just the items you just checked out rather than everything today, or everything currently checked out altogether. I can narrow down something close to this session with some template toolkit and time logic, but that is rather complicated for some libraries, and isn't foolproof. It would be preferred if Koha kept track of checkout sessions and offered an easy to implement option in the slip template. This is very needed and common. You don't go the grocery store and get a receipt for everything you bought that day. Just for that transaction. This would line up with current practices. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 38252] New: Zebra's Record-control-number does not include $w for 760, 762, 765, 767, 786, 788
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '26

10 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38252 Bug ID: 38252 Summary: Zebra's Record-control-number does not include $w for 760, 762, 765, 767, 786, 788 Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org INCLUDED 770 772 773 774 775 776 777 780 785 787 NOT INCLUDED 760 762 765 767 786 788 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 39287] New: Improve "Show volume" search with a more specialized search index
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '26

10 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39287 Bug ID: 39287 Summary: Improve "Show volume" search with a more specialized search index Change sponsored?: --- 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl, michaela.sieber(a)kit.edu Currently the rcn index used to search for volumes contains all $w subfields from 7xx and 8xx linking fields. In some cases this is too broad, even tho we are additionally limiting to monographs. Example: Search volumes will also find - records with a 775$w - other edition - records with a matching 780/785$w - preceeding or succeeding ... A specific index for searching volumes (rcn-volumes) should contain: - 773$w (we still need to limit to monographic, because these could also be analytcal links) - 800$w - 810$w - 811$w - 830$w Once the index is defined we can update the XSLT and the method for determining if the "Show volumes" link should be shown to use it and have a correct result list. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 40990] New: Checkout override allowed without permissions when item has circulation alert
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '26

10 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40990 Bug ID: 40990 Summary: Checkout override allowed without permissions when item has circulation alert Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: maxeinergl(a)gcc.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Koha will allow staff who do not have force_checkout permissions to check out items beyond the maximum number per type allowed if the item has a circulation alert. In this case a warning is offered but staff can click to continue with the checkout. This behavior is different than when items do not have the circulation alert ; in that case the same staff hit a hard block and cannot override the limitation. This may be related to bug 38540. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 26423] New: Cannot find patron with no cardnumber attached to hold, if HidePatronName system preference set
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '26

10 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26423 Bug ID: 26423 Summary: Cannot find patron with no cardnumber attached to hold, if HidePatronName system preference set Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: minna.kivinen(a)hamk.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When system preference HidePatronName is set, there is showing only patron cardnumber when looking at title holds. If patron has no cardnumber, there is showing nothing. There is no way to find the patron attached to hold. There should be a link to patron even when no cardnumber. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 40984] New: Synchronise before_ and after_authority_action hook signatures with biblio action hooks
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '26

10 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40984 Bug ID: 40984 Summary: Synchronise before_ and after_authority_action hook signatures with biblio action hooks Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: Hackfest Severity: minor Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: fridolin.somers(a)biblibre.com, kyle(a)bywatersolutions.com, m.de.rooy(a)rijksmuseum.nl, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com, wainuiwitikapark(a)catalyst.net.nz Following the work on bug 36343, which standardized the signatures for before_biblio_action and after_biblio_action hooks to include a payload parameter, a similar inconsistency exists within the authority hooks. To improve the consistency and predictability of the plugin hook system, we should align the authority action hooks with the syntax established for biblios. This bug covers two related issues: Update after_authority_action hook signature: An after_authority_action hook already exists, but its signature is missing the payload parameter. We should update this hook to include the payload, bringing it in line with after_biblio_action. A deprecation period and warning should be introduced for the older signature to ensure backward compatibility for existing plugins. Create before_authority_action hook: There is currently no equivalent before_authority_action hook. We should create this new hook to allow plugins to interact with authority records before an action (like saving) is completed. This new hook should be implemented with a signature that is consistent with before_biblio_action from the outset, including the payload parameter. Completing this work will provide a more coherent and powerful interface for plugins that interact with both bibliographic and authority records. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 30657] New: Make patron attributes available via Template Toolkit in overdues
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '26

10 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30657 Bug ID: 30657 Summary: Make patron attributes available via Template Toolkit in overdues 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When using Template Toolkit to fetch patron values, one should be able to fetch patron attribute values. This would be useful both for printing those values into the notice content and for using those values in logic to vary the notices per patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 104

[Bug 35288] New: ApplyFrameworkDefaults add plugin to add more fine grained defaults handling
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '26

10 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35288 Bug ID: 35288 Summary: ApplyFrameworkDefaults add plugin to add more fine grained defaults handling 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: koha(a)trust-box.at QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The "new" ApplyFrameworkDefaults option is to coarse sometimes ie quite often you also want to apply default values even if then field wasn't empty before e.g. on duplicating a new controlnumber should be generated etc so I suggest (and already wrote) a new plugin hook (see https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33669) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29