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

[Bug 38101] New: ES skips records with huge fields
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '25

24 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38101 Bug ID: 38101 Summary: ES skips records with huge fields Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org I saw a case in the wild, where the staff member copied and pasted some legal text from a PDF into a 500 field. Then the record was not able to be found using ES. The reason is fairly simple: ES has a max size it will accept for a phrase index. To reproduce: 1. Have KTD running with ES: $ ktd --proxy --es7 up -d 2. Perform a search 3. Pick the first result for edition 4. Find a cool Wiki page with lots of paragraphs 5. Copy all of the paragraphs and put them on a 500$a field for the record. 6. Repeat 2 => FAIL: The record is not found 7. Reindex manually: $ ktd --shell k$ perl misc/search_tools/rebuild_elasticsearch.pl --biblios --where "biblionumber=3" -v -v => FAIL: You get something like: ``` [22229] Committing final records... One or more ElasticSearch errors occurred when indexing documents at /kohadevbox/koha/Koha/SearchEngine/Elasticsearch/Indexer.pm line 148. [22229] There were errors during indexing Record #3 Document contains at least one immense term in field="note.raw" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped. Please correct the analyzer to not produce such terms. The prefix of the first immense term is: '[10, 109, 117, 115, 116, 97, 102, 97, 32, 102, 117, 101, 32, 101, 108, 32, 115, 101, 103, 117, 110, 100, 111, 32, 104, 105, 106, 111, 32, 100]...', original message: bytes can be at most 32766 in length; got 32771 (illegal_argument_exception) : max_bytes_length_exceeded_exception (bytes can be at most 32766 in length; got 32771) [22229] Total 1 records indexed ``` -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 49

[Bug 38422] New: Add data-isbn and data-title to lists for plugin cover images
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '25

24 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38422 Bug ID: 38422 Summary: Add data-isbn and data-title to lists for plugin cover images Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: matt.blenkinsop(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org It isn't possible to display plugin cover images on the OPAC lists view - we need to enable the plugin method and pass the item data to the element -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 38367] New: offset is wrong on plugins-disabled.tt page
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '25

24 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38367 Bug ID: 38367 Summary: offset is wrong on plugins-disabled.tt page Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface 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 To recreate: 1. Go to your koha-conf.xml and turn plugins off: <enable_plugins>0</enable_plugins> 2. Go to Administration -> Plugins 3. The text is not correctly offset. ( Bootstrap class is col-sm-offset-3 and should be offset-sm-3 in Bootstrap 5 ) ` -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 38350] New: Fix style of sidebar form clear buttons
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '25

24 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38350 Bug ID: 38350 Summary: Fix style of sidebar form clear buttons Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: Academy Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org In cases where sidebar forms have a submit button alongside a clear button, the submit button is supposed to be larger than the clear button. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 32135] New: Ability to batch cancel transfers
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32135 Bug ID: 32135 Summary: Ability to batch cancel transfers Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: madamyk(a)ckls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com For consortiums and other large systems, it would be helpful to have the ability to batch cancel transfers, or cancel more than one at a time. Most likely the easiest place to do this would be on the Transfers to Receive page, where you might be able to add a "Cancel Transfer" checkbox instead of (or in addition to) the button. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 37193] New: We could perhaps promote the community and it's tools more from inside Koha
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37193 Bug ID: 37193 Summary: We could perhaps promote the community and it's tools more from inside Koha Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org It occurred to me today that other than linking out to the manual.. we don't really promote the community from Koha itself. I can't see any link to koha-community.org, chat.koha-community.org, bugs.koha-community.org or dashboard.koha-community.org anywhere. Perhaps we could add some to the about area to encourage more engagement with the community projects? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 26625] New: Add a mojolicious section in $KOHA_CONF
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26625 Bug ID: 26625 Summary: Add a mojolicious section in $KOHA_CONF Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 20582 This will allow to configure hypnotoad (and probably other things too in the future) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20582 [Bug 20582] Turn Koha into a Mojolicious application -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 32423] New: Allow guarantor to renew guarantee's checkouts
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32423 Bug ID: 32423 Summary: Allow guarantor to renew guarantee's checkouts Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org >From bug 3591 Right now, if AllowStaffToSetCheckoutsVisibilityForGuarantor or AllowPatronToSetCheckoutsVisibilityForGuarantor is set and the patron has consented to show their checkouts to their guarantor, the guarantor can see their guarantee's checkouts when logging into their own account in the OPAC. However, if they want to renew their guarantee's checkouts, they must log out and log in as their guarantee (or nag them if they don't have access). It would be great if the guarantor could renew from their own account. It could be the same as AllowStaff/PatronToSetCheckoutsVisibilityForGuarantor in the sense that the guarantee would have to "agree" to it to preserve confidentiality for older guarantees. (The use case I'm seeing the most is a family with small children, where the parent could renew all their family's checkouts from their own account.) -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 39348] New: Supplementary fields order in tables should be manageable
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39348 Bug ID: 39348 Summary: Supplementary fields order in tables should be manageable Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If a supplementary field is created with the "searchable" option it is displayed in the appropriate table, but there is no way to define its position in the table. It should be useful for improving usabilty of tables. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 34495] New: AutomaticConfirmTransfer does not confirm if the check-in form is resubmitted
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34495 Bug ID: 34495 Summary: AutomaticConfirmTransfer does not confirm if the check-in form is resubmitted Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 33300 Bug 29792 added a new system preference, AutomaticConfirmTransfer, to control the behavior of a transfer when the user clicked away from the "Wrong Transfer" modal without selecting anything. (assuming TransfersBlockCirc is set to "Don't block") With the syspref set to automatically confirm, it works as intended if the user literally clicks away from the modal using the mouse. However, if the user submits the check-in form again without selecting an option on the modal (i.e. by scanning the next item, or accidentally double-scanning the item initiating the transfer), then the transfer is not confirmed. It looks like this is happening because the automatic confirmation is triggered when the modal is hidden by Bootstrap event. If the check-in form is resubmitted, it doesn't actively hide the modal before reloading the page, so the automatic confirmation is not triggered. To reproduce: 0. Configure sysprefs and circulation rules: a. TransfersBlockCirc to Don't block b. AutomaticConfirmTransfer to Do c. In the circulation rules, set the default return policy to "Item returns home" 1. Find an item that belongs to a different library and check it in 2. When the transfer modal appears, click away from the modal. -> Notice the animation - the modal appears to fade upwards. 3. Query the transfer table -> Notice that there is a transfer with values for daterequested and datesent 4. Check the item in again 5. When the Wrong Transfer modal appears, click away from the modal. -> Notice the animation - the modal appears to fade upwards. 6. Query the transfer table -> Notice that the previous transfer was canceled, and there is a new transfer with values for daterequested and datesent 7. Repeat steps 1-6, except instead of clicking away from the modals, press Enter on the keyboard instead -> Notice that the animation no longer appears - the modals simply disappear when the page is reloaded -> Notice that after the Wrong Transfer modal is bypassed like this, the transfer table shows that the previous transfer was canceled, and there is a new transfer with a value for daterequested but no value for datesent Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33300 [Bug 33300] Wrong system preference name AutomaticWrongTransfer -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3