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

[Bug 41133] New: Suggestions table sharing localStorage for all tabs can prevent records from loading
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41133 Bug ID: 41133 Summary: Suggestions table sharing localStorage for all tabs can prevent records from loading Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: blawlor(a)clamsnet.org QA Contact: testopia(a)bugs.koha-community.org On suggestion.pl the local storage DataTables_acqui_suggestions_suggestions which saves the state for pagination is shared for all tabs, which can cause tabs to load with a bad state and fail to load records. To recreate: 1. Use ktd --dbshell to add a bunch of random suggestions with different statuses: INSERT INTO suggestions (suggestedby, suggesteddate, title, status) SELECT borrowernumber, '2025-10-29', firstname, ELT(0.5 + RAND() *6, 'ASKED', 'CHECKED', 'ACCEPTED', 'REJECTED', 'ORDERED', 'AVAILABLE' ) from borrowers; 2. If you are lucky you will have one tab with more than 20 records and one with less than 20, if not use the ui to adjust the statuses so that you do 3. Click on a tab with more than 20 records 4. Click Next > to go to the second page 5. Notice in local storage now DataTables_acqui_suggestions_suggestions.start is now 20 6. Click on a tab with fewer than 20 records 7. Notice the table says something illogical like: Showing 21 to 11 of 11 entries 8. And no records load :( 9. Click <<First to fix the pagination issue 10. Notice DataTables_acqui_suggestions_suggestions.start is now 0 again 11. The table loads with records :) Showing 1 to 11 of 11 entries -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 43321] New: Remove event attribute from search filter administration
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43321 Bug ID: 43321 Summary: Remove event attribute from search filter administration Initiative type: --- Sponsorship Sponsored status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, testopia(a)bugs.koha-community.org Blocks: 38407 Target Milestone: --- On the search filter administration page there is an onclick attribute on the delete button which should be removed in favor of defining the event in the page's JavaScript. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38407 [Bug 38407] Eliminate event handler attributes in the staff interface -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 43380] New: Koha will generate spurious print notices if itiva is enabled and a patron has only selected phone notices
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43380 Bug ID: 43380 Summary: Koha will generate spurious print notices if itiva is enabled and a patron has only selected phone notices Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- If a patron only has itiva notices enabled ( and possibly sometimes with other transports enabled, depending on sorting ), Koha will always generate a print notice for them. Take this excerpt from Reserves.pm: 2086 while ( my ( $mtt, $letter_code ) = each %{ $messagingprefs->{transports} } ) { 2087 if ( 2088 ( $mtt eq 'email' and not $to_address ) # No email address 2089 or ( $mtt eq 'sms' and not $patron->smsalertnumber ) # No SMS number 2090 or ( $mtt eq 'itiva' 2091 and C4::Context->preference('TalkingTechItivaPhoneNotification') 2092 ) # Notice is handled by TalkingTech_itiva_outbound.pl 2093 or ( $mtt eq 'phone' and not $patron->phone ) # No phone number to call 2094 ) 2095 { 2096 unless ($notification_sent) { 2097 $notification_sent++; 2098 &$send_notification( 'print', 'HOLD' ); 2099 } 2100 next; 2101 } 2102 2103 &$send_notification( $mtt, $letter_code, $messagingprefs->{wants_digest} ); 2104 } 2105 } Lines 2090/2091 will always be true if itiva is enabled. If the patron has only itiva enabled ( or itiva happens to be the first transport handled in the loop ), the value check at line 2096 will always be false, and thus the call to send_notification for the print version will be triggered at line 2098. It seems that we should replace lines 2090/2091 with something like: or ( ( $mtt eq 'itiva' and !C4::Context->preference('TalkingTechItivaPhoneNotification') ) or ( $mtt eq 'itiva' and not $patron->phone ) ) so if they are to be sent an itiva notice but itiva is not enabled, or itiva *is* enabled but they don't have a voice phone number set, *then* send the print notice. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 41049] New: Add additional deleting capabilities to the cataloging macros
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41049 Bug ID: 41049 Summary: Add additional deleting capabilities to the cataloging macros Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: maxeinergl(a)gcc.edu QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be helpful to have syntax added to the Advanced Editor's cataloging macros for the following: 1) ability to delete fields based on indicator 2) ability to delete subfields on all instances of a field, not just the first instance of the subfield / first instance of the field. A use case scenario would be importing records from Z39.50 sources and using a macro to strip fields/subfields that are always unwanted. Deleting fields based on indicator would allow one to strip subjects from unwanted thesauri, for example 650 _1... for a juvenile SH or 650 _2 for MESH. Deleting subfields on all instances would allow one to strip coded and linking subfields from authorized heading fields. Sometimes the same subfield repeats in the same instance of the field (for example, multiple $4's in a 100 field), and sometimes a field number has multiple instances (for example, multiple 650 fields, all with $0 linking subfields). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 43384] New: Errors in CHECKOUT or CHECKIN templates result in error screen in staff client
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43384 Bug ID: 43384 Summary: Errors in CHECKOUT or CHECKIN templates result in error screen in staff client Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- To recreate: - have a patron who has an email address and is set to receive both CHECKIN and CHECKOUT notices via email - edit the email templates for both CHECKIN and CHECKOUT notices such that they contain Template Toolkit errors. For example, add "[% IF 1==1 %]" to the notice without a corresponding "[% END %]" - confirm your notice shows an error in the notice edit screen: "file error - parse error - input text line 6: unexpected end of input at /kohadevbox/koha/tools/letter.pl line 211." - check an item out to your patron. On KTD you will end up on an Error Trace screen that repeats the same template error seen above. On a production site you should see a "An error has occurred! Error 500" - reload your patron, see the checkout was successful, despite the errror - check your item again, get another error - reload your patron, see the checkin was successful despite the error -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 43383] New: problem adding to list or cart when using browser's back button
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43383 Bug ID: 43383 Summary: problem adding to list or cart when using browser's back button Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 Target Milestone: --- To recreate: 1. Do a catalog search that brings up multiple results 2. Check the checkbox of in the left column for the first two results 3. Click on the title of the 3rd result to take you to the details page for that item 4. Use the borwser's back button to return to the search results 5. Notice the first 2 titles are still checked. 6. Now check the 3rd result and click 'Add to list' 7. Only the 3rd title is added, even though all 3 are checked. 8. Try steps 1 - 7 again but with 'Add to cart', same behavior. 9. Try setps 1 - 7 again but with 'Place hold', all 3 items are selected. I get this behavior in both Chrome and Firefox. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 42332] New: Remove conditional TT tags from tables thead
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42332 Bug ID: 42332 Summary: Remove conditional TT tags from tables thead Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 41604 Tables that are configurable (admin/columns_settings.pl) cannot have conditional TT tags in their thead. The same number of columns must always be in the DOM when DataTables is initialized. Then we hide the column in the JS part. This depends on the visibility_condition flag added by bug 41604. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41604 [Bug 41604] Impossible to hide Checkin column in issues-table in circ/circulation.pl -- You are receiving this mail because: You are watching all bug changes.

1 153

[Bug 41674] New: Add template plugin for linking to system preferences based on user permission
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41674 Bug ID: 41674 Summary: Add template plugin for linking to system preferences based on user permission 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: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org There are many places in templates where we link to a system preference and we are inconsistent about whether these links are dependent on the permission of the logged-in user. I propose to add a template plugin which handles the permission check. [% "RequireChoosingExistingAuthority" | html | $LinkPref %] For a user with 'CAN_user_parameters_manage_sysprefs' permission it outputs: <a class="link_preference" href="admin/preferences.pl?op=search&ok=Search&searchfield=RequireChoosingExistingAuthority">RequireChoosingExistingAuthority</a> For a user without permission it outputs: <span class="link_preference">RequireChoosingExistingAuthority</span> -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 32196] New: One should be able to remove a borrower relationship whenever one exists
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32196 Bug ID: 32196 Summary: One should be able to remove a borrower relationship whenever one exists Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 12446 Per bug 32195, there is still at least one way for a patron to end up with a guarantor in a category that does not allow guarantors. When that happens, the patron edit screen does not show one the relationship and therefore the relationship cannot be removed. One should *always* be able to remove an existing relationship. To recreate: 1: have a patron category where CanBeGuarantee is set to Yes. 2: Create a patron in that category, give them a guarantor 3: edit the patron category to set CanBeGuarantee to No 4: confirm your patron still has a guarantor that shows on the details page, but the guarantor no longer shows on the edit screen 5: this means the guarantor cannot be removed :( Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12446 [Bug 12446] Enable an adult to have a guarantor -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 43246] New: Entering dates with a keyboard creates due dates with time set to 00:00
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43246 Bug ID: 43246 Summary: Entering dates with a keyboard creates due dates with time set to 00:00 Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: janne.seppanen(a)lahti.fi QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- One can enter due dates manually with the current datepicker in Koha. When picking dates from the calendar widget, Koha creates due dates with 23:59 as the latest return time on that date. However, when entering the date with a keyboard the time sets to 00:00, meaning that if the patron returns their loans on the due date, they're already late. There seems to have been a similar bug with the old date widget, maybe this bug has returned with the release of the new datepicker widget? https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34939 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2