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

[Bug 35899] New: Performance improvements for build_holds_queue
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35899 Bug ID: 35899 Summary: Performance improvements for build_holds_queue Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com On a large and busy system the holds queue can take several minutes to build adding a significant load to the database and koha server. I have profiled the script and have noticed two major inefficiencies: 1. Calls to C4::Circulation::GetBranchItemRule constitute roughly 35% of the runtime. But this method can easily be memoized. 2. With LocalHoldsPriority enabled, expensive checks are made for all available items, even if it is only relevant to do these checks for local items. Depending on how the system is configured, either the unnecessary loading of patron objects, or calls to _checkHoldPolicy can take considerable time. I have prepared two patches which together cuts the runtime of the script with abouth 50% if LocalHoldsPriority is enabled. Profiling result before: https://bv-test-opac.biblioteket.nu/resources/before/index.html Profiling result after: https://bv-test-opac.biblioteket.nu/resources/after/index.html -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 37743] New: MARC21 810$t is used in XSLT templates but is not editable by default
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37743 Bug ID: 37743 Summary: MARC21 810$t is used in XSLT templates but is not editable by default Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: olli-antti.kivilahti(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl XSLT-template in question: intranet/htdocs/intranet-tmpl/prog/en/xslt/MARC21slimUtils.xsl Field 810$t is used to populate a search query, so it looks pretty important: <a><xsl:attribute name="href"><xsl:value-of select="$searchurl"/>?q=se,phr:"<xsl:value-of select="str:encode-uri(marc:subfield[@code='t'], true())"/>"&q=au:"<xsl:value-of select="str:encode-uri(marc:subfield[@code='a'], true())"/>"</xsl:attribute> -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 37201] New: Add a syspref to allow or not a checkout if a expired booking exists for the same patron
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37201 Bug ID: 37201 Summary: Add a syspref to allow or not a checkout if a expired booking exists for the same patron Change sponsored?: --- 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: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hello :) I've worked on a way to prevent checkout to patron if this same patron has a booking expired for the same item.. I think it's a setting that might not suit everyone, so I've introduced a new system preference. I'll put my patch in place and await your comments. Thanks ^^ -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 37885] New: Add ability to disable message queue processing
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37885 Bug ID: 37885 Summary: Add ability to disable message queue processing Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org There exist services that libraries utilize as an alternative to processing the message queue. These services may utilize the queued messages and send them from outside of Koha. Sometimes these services utilize the API or reports while other times they utilize a plugin. It would be beneficial to be able to disable running the message queue processor altogether, or to only execute the plugin hook related to message queue processing ( before_send_messages ) to limit the processing of messages to those handled by plugins. I think a new system preference along the lines of "Process/Don't process/Process only via plugins" would be good, but haven't quite come up with a sentence that makes sense. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 37359] New: Advanced editor should work with unimarc
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37359 Bug ID: 37359 Summary: Advanced editor should work with unimarc 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: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In the manual I read for EnableAdvancedCatalogingEditor : "This feature does not currently include any support for UNIMARC or NORMARC fixed fields." Is it true? If so, it could be an improvement to make this feature available for UNIMARC installs -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 31507] New: When printing barcode range labels library name does not print
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '25

06 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31507 Bug ID: 31507 Summary: When printing barcode range labels library name does not print Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org With the ability to print barcode labels from a range, using the Home or Holding description data within the label layout, it does not print any info, since by default, these are barcodes that do not have items yet, and therefore, no home or holding data. It would be really helpful to have a way to have the library info appear without having to manually enter the library name in the fields data. This is particularly important for libraries with multiple branches where you don't want to have to change the library name, nor have a lot of different layouts. Perhaps the default for this scenario could be the logged in library if there is no home or holding? -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 37856] New: Some SUSHI providers require the platform parameter
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '25

06 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37856 Bug ID: 37856 Summary: Some SUSHI providers require the platform parameter Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: pedro.amorim(a)ptfs-europe.com Reporter: pedro.amorim(a)ptfs-europe.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, michaela.sieber(a)kit.edu, pedro.amorim(a)ptfs-europe.com The harvest_sushi method produces the following URL when harvesting SUSHI data: <provider_url>/reports/<report_type>?customer_id=<customer_id>&requestor_id=<requestor_id>&api_key=<api_key>&begin_date=<begin_date>&end_date=<end_date> Some providers require the 'platform' parameter. Docs here: https://app.swaggerhub.com/apis/COUNTER/counter-sushi_5_0_api/5.0.2#/defaul… We need to look for a way to identify when/if a provider requires this parameter, and add it to the URL if so. The provider in question is ScienceDirect: https://registry.countermetrics.org/platform/ab4d3560-1165-491d-a67e-9359d0… The 'platform parameter required' entry is unchecked even though this provider requires it. We should consider using this to identify if the parameter is required or not. -- You are receiving this mail because: You are watching all bug changes.

1 53

[Bug 28492] New: Hyphen in branchcode gives wrong search results
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '25

05 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28492 Bug ID: 28492 Summary: Hyphen in branchcode gives wrong search results 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org A client noticed that when limiting by branch, some search results were wrong and after a bit of digging, I found that it happens when the branchcode contains a hyphen. I was able to recreate the situation as follows: 1) Go to Administration > Libraries and add the libraries - Fairfield (branchcode FFL) -- if you have the default database, this library should already exist - Fairfield North (branchcode FFL-N) - Fairfield South (branchcode FFLS) 2) Add an item to record A with holding branch FFL-N 3) Add an item to record B with holding branch FFLS 4) reindex if necessary 5) In Advanced search, search for record A and limit to Fairfield North library -- record is in the results - OK 6) In Advanced search, search for record A and limit to Fairfield library -- record is in the results! - NOT OK 7) In Advanced search, search for record B and limit to Fairfield South library -- record is in the results - OK 8) In Advanced search, search for record B and limit to Fairfield library -- record is not in results - OK As you can see, the search for branchcode FFL-N and for branchcode FFL give the same results. The problem was originally found by a client using 18.05.03. I was able to recreate in 20.05.08 and master (21.06.000), always with Zebra. I didn't try with ES because mine is currently broken :( -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 19220] New: Allow XSLT procsessing for Z39.50 authority targets like for bibliographic targets
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '25

05 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19220 Bug ID: 19220 Summary: Allow XSLT procsessing for Z39.50 authority targets like for bibliographic targets Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers 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 When configuring a bibliographic Z39.50 targets it's possible to list XSL scripts that change the record on import. While the option is also offered when adding authority Z39.50 targets, it doesn't work/hasn't been implemented. It would be great if this feature was available for both types of targets. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 58

[Bug 32380] New: There should be a staff side equivalent to PatronSelfRegistrationEmailMustBeUnique
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '25

05 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32380 Bug ID: 32380 Summary: There should be a staff side equivalent to PatronSelfRegistrationEmailMustBeUnique 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We have the ability to enforce unique email address from self reg. We should have a staff side equivalent. When using SSO it can be problematic to have the same email address on different accounts. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3