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

[Bug 39417] New: Allow for editing/deletion of default SUGGEST_STATUS authorized values
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39417 Bug ID: 39417 Summary: Allow for editing/deletion of default SUGGEST_STATUS authorized values Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: heather(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There are libraries who do not use the default SUGGEST_STATUS authorized values for indicating the status of a purchase suggestion in the staff interface/OPAC. For example, libraries would rather use terminology like "Declined" as opposed to "Rejected". While it is possible to add more authorized values to this auth value category, it would be nice if those default values could be Edited or Deleted by staff, if desired. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 43033] New: Holds queue allocate with transport cost matrix can choose impossible holds
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43033 Bug ID: 43033 Summary: Holds queue allocate with transport cost matrix can choose impossible holds Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- Something about the retries and the way we build the matrices can fail when there are more holds than items. We have seen instances in libraries where items are being selected for the queue that are not allowed to transfer via the branch limits or the cost matrix -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 23817] New: Searching by patron phone number is contingent on how it was entered
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23817 Bug ID: 23817 Summary: Searching by patron phone number is contingent on how it was entered Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If a library chooses to enter their patron phone numbers in as xxx-xxx-xxxx when creating the patron record; then when the phone number is searched with the filters, the library must always use hyphens when searching or the search will not work. It would be nice that the number could be searched in the filters with either hyphens or no hyphens and the library would get the same results. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 65

[Bug 43117] New: t/Form_MessagingPreferences.t does not use Test::NoWarnings
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43117 Bug ID: 43117 Summary: t/Form_MessagingPreferences.t does not use Test::NoWarnings Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 34776 Target Milestone: --- From commit 6cc683b518223479f0c427a8305071fbd9581b5e Bug 34776: Unit tests -use Test::NoWarnings; -use Test::More tests => 2; +use Test::More tests => 1; +use Test::MockModule; +#use Test::NoWarnings; Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34776 [Bug 34776] Patron messaging preferences are lost when an error occurs during new account creation -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 42993] New: Koha::Edifact::Transport should log transport failures via Koha::Logger
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42993 Bug ID: 42993 Summary: Koha::Edifact::Transport should log transport failures via Koha::Logger Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Koha::Edifact::Transport reports every transport failure (no transport configured, connect failure, directory-change failure, file-listing failure and per-file download/upload failure) with carp. Under misc/cronjobs/edi_cron.pl these go to STDERR, so on a normal cron run the messages are lost: EDI simply goes quiet with nothing in editrace.log to explain why. This routes those failures through Koha::Logger on the 'edi' interface (the same interface edi_cron.pl already uses) so they are recorded in the EDI log. The two ingest()-level data warnings (duplicate filename, unreadable file) are intentionally left as carp: one is asserted by the existing unit test and neither is a transport failure. No change to the transfer logic. Test plan: 1. prove t/db_dependent/Koha/Edifact/Transport.t 2. Point an EDI account at an unreachable transport and run misc/cronjobs/edi_cron.pl; confirm the failure is now written to the EDI log rather than only to STDERR. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 42924] New: Restore default MaxAge for CSRF token
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42924 Bug ID: 42924 Summary: Restore default MaxAge for CSRF token Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Bug 17110 lowered the default MaxAge for the CSRF token from 1 week to 8 hours, but that has led to increased usability problems for negligible security gains. I propose to restore the default which is closer to the per-session approach for CSRF tokens which tends to be the default in many web frameworks like Django. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 42653] New: ILL request with log entries from multiple backends causes 500 error
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42653 Bug ID: 42653 Summary: ILL request with log entries from multiple backends causes 500 error Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 39589] New: Search returns 'No results found' despite existing matching records
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39589 Bug ID: 39589 Summary: Search returns 'No results found' despite existing matching records 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: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org This issue occurs when the records on the first page of results are not displayed. The message "No results found" is shown, and it is not possible to access records on other pages. To test 1. Set the following system preferences: OPACnumSearchResults to 5 OpacHiddenItemsHidesRecord to Hide OpacHiddenItems to withdrawn: [1] 2. Create 6 bibliographic records with the following titles: "notice test 1" "notice test 2" "notice test 3" "notice test 4" "notice test 5" "notice test 6" 3. For the first 5 records, add an item with Withdrawn status. 4. For "notice test 6", add an item with Available status. 5. In the OPAC interface, search for "notice test". ---> The message "No results found!" appears, and "notice test 6" is not visible. -- You are receiving this mail because: You are watching all bug changes.

1 66

[Bug 17921] New: Shelf Browser does not take OpacSuppression or OpacHiddenItems into consideration
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17921 Bug ID: 17921 Summary: Shelf Browser does not take OpacSuppression or OpacHiddenItems into consideration 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Items that shouldn't be displayed in the OPAC are displayed in the shelf browser The links work as expected (redirect to opac-blocked or 404) but we should not display them in the first place -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 42968] New: 505 MARC field label is missing in the staff interface
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42968 Bug ID: 42968 Summary: 505 MARC field label is missing in the staff interface Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Cataloging Assignee: Laura.escamilla(a)bywatersolutions.com Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- The staff interface displays the contents of the MARC 505 field but does not display the "Contents:" label that appears in the OPAC. This results in an inconsistency between the OPAC and staff interface and makes it less clear what the displayed information represents. To recreate: 1.Create or locate a bibliographic record with data in the MARC 505 field. 2.View the record in the OPAC. 3.Note that the 505 field is displayed with the "Contents:" label. 4.View the same record in the staff interface. 5.Notice that the 505 field is displayed without the "Contents:" label. -- You are receiving this mail because: You are watching all bug changes.

1 13