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

[Bug 42423] New: Submit button in patron search from header never submits
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42423 Bug ID: 42423 Summary: Submit button in patron search from header never submits Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com It looks like there's a bug in bug 41040 that prevents any patron search from the header and not just empty searches. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 41040] New: Empty patron search from the header should not trigger a patron search
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41040 Bug ID: 41040 Summary: Empty patron search from the header should not trigger a patron search Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com If the "arrow" button on the patron search is clicked with no value in the textbox, it redirects to members/members-home.pl and performs a search with no value automatically. It makes more send for it to behave as the "Patrons" link in the navbar that directs to members-home.pl where the librarian can then perform a more advanced search. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 66

[Bug 41761] New: Updating accountlines note sets accountlines.date to current date
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41761 Bug ID: 41761 Summary: Updating accountlines note sets accountlines.date to current date Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 37211 When updating the note in an accountline, both accountlines.timestamp and accountlines.date get updated to the current date and time. Accountlines.date is meant to remain constant as the time of creation for this entry. Updating it has a serious impact on the data. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37211 [Bug 37211] All notes in the patron account transactions table should be editable -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 42521] New: Cannot login from suggestion.pl
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42521 Bug ID: 42521 Summary: Cannot login from suggestion.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major 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: 39055 DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Unknown column 'login_op' in 'WHERE' at /kohadevbox/koha/Koha/Objects.pm line 401 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39055 [Bug 39055] Unauthenticated are not redirected properly in reports module after login -- You are receiving this mail because: You are watching all bug changes.

1 31

[Bug 42010] New: Include escaping when using PO numbers in EDI acqusitions
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42010 Bug ID: 42010 Summary: Include escaping when using PO numbers in EDI acqusitions Initiative type: --- Sponsorship Sponsored status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: hdunne-howrie(a)westminster.gov.uk, kyle(a)bywatersolutions.com, testopia(a)bugs.koha-community.org Depends on: 20253 Blocks: 38195 In bug #20253 we added support for using PO numbers as basket names.. we neglected to add escaping to the resulting basketnames that could then be used in corresponding orders. This bug servers to add that escaping as a follow-up to the original enhancement. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20253 [Bug 20253] Optionally use buyer's purchase order number from EDIFACT quote in basket name https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38195 [Bug 38195] EDI/Edifact classes should use Koha::Objects instead of plain DBIC -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 42253] Stored XSS in advanced editor in Macro name
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42253 Caroline Cyr La Rose <caroline.cyr-la-rose(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs documenting |RESOLVED Resolution|--- |FIXED --- Comment #9 from Caroline Cyr La Rose <caroline.cyr-la-rose(a)inlibro.com> --- Bug fix, nothing to add or edit in the Koha manual. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42068] New: Update on bug 26993 breaks items deletions with a corrupted foreign key
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42068 Bug ID: 42068 Summary: Update on bug 26993 breaks items deletions with a corrupted foreign key Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org On bug 26993 we turned off foreign key cheks to remove a unique constraint, then enabled them This meant the existing rows got wrong :-) To recreate: 1 - Checkout 25.11.x - reset_all 2 - Enable StoreLastBorrower 3 - Issue an item 4 - Ensure item has a row in items_last_borrower SELECT * FROM items_last_borrower 5 - Checkout main 6 - updatedatabase 7 - Try to delete any item, doesn't have to be the one you issued DELETE FROM items WHERE itemnumber=93; 8 - ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (`koha_kohadev`.`items_last_borrower`, CONSTRAINT `items_last_borrower_ibfk_1` FOREIGN KEY (`itemnumber`) REFERENCES `items` (`itemnumber`) ON DELETE CASCADE ON UPDATE CASCADE) TO fix you must recreate the constraint: ALTER TABLE items_last_borrower DROP FOREIGN KEY items_last_borrower_ibfk_1; ALTER TABLE items_last_borrower ADD INDEX itemnumber (itemnumber); ALTER TABLE items_last_borrower ADD CONSTRAINT items_last_borrower_ibfk_1 FOREIGN KEY (itemnumber) REFERENCES items (itemnumber) ON DELETE CASCADE ON UPDATE CASCADE; -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 26993] New: Allow StoreLastBorrower to retain up to 2 previous patrons
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26993 Bug ID: 26993 Summary: Allow StoreLastBorrower to retain up to 2 previous patrons 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 14945 Various workflows and circumstances can result in the "last returned by" value stored by StoreLastBorrower getting overwritten sooner than a library might like. For example, a patron may find the item they've checked out was damaged by the previous patron. They put the item in the bookdrop on their way into the library and then alert staff to the damage when they check out their next batch of items. By that time, the damaged item has been checked in, our imaginary patron shows as "last returned by," and we have no record there of who had it previously. We could alleviate this by adding a third option to the StoreLastBorrower system preference, so that one can choose "Do not store," "store 1," or "store 2." This entire feature would still be optional for libraries that don't want to keep this data. Additionally, bug 23260 is adding the ability to clear this data after a period of time using cleanup_database. These factors help mitigate the privacy concerns inherent to the matter. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14945 [Bug 14945] Add the ability to store the last patron to return an item -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 85

[Bug 43261] New: Public biblio API ignores OpacSuppressionByIPRange
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43261 Bug ID: 43261 Summary: Public biblio API ignores OpacSuppressionByIPRange Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major 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: 43258 Target Milestone: --- GET /api/v1/public/biblios/:id checks OpacSuppression but does not check OpacSuppressionByIPRange. This means suppressed records are unconditionally hidden from the public API even for clients within the allowed IP range. Additionally, clients outside the IP range can still access suppressed records if they know the biblio_id, since the IP range check is missing entirely. Impact: information disclosure - suppressed bibliographic records (which may be suppressed for legal, privacy, or collection management reasons) are accessible via the public API regardless of IP restrictions. Affected endpoints: - GET /api/v1/public/biblios/:id (Koha::REST::V1::Biblios::get_public) Related: bug 43258 introduces Koha::IP and Koha::REST::Plugin::Restrictions which provide the fix mechanism. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43258 [Bug 43258] Add a centralized IP range matching helper -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 43266] New: Missing information on circ restrictions after override
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43266 Bug ID: 43266 Summary: Missing information on circ restrictions after override Initiative type: --- Sponsorship --- status: 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: bdaeuber(a)cityoffargo.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- When checking out, if a staff person overrides a checkout and clicks "Remember for the session for this patron", then checks out an item with a different restriction, information about that checkout is missing from the confirm checkout box. The box only says "This patron can't check out this item per library circulation policy." but doesn't contain information that's usually there (especially how many of that item type the user has out). To recreate: 1. Create a circ rule for an item type with zero checkouts allowed. 2. In the defaul checkout, hold policy by patron category, set a patron category to have some number of checkouts (we'll say 2 for this example). 3. Check out 2 regular (non-restricted) items types to a patron of the same type you set up in step 2. 4. Check out a 3rd regular item type to that patron. When you override the checkout, click "Remember for the session for this patron" and then "Yes, check out" 5. Check out an item of the type you set up in step 1. 6. The popup that appears is missing information such as the item type, number of items of that type out, etc. Fairly frequently we'll get users who come in and drop off a large number of items, then go to check out more, causing them to exceed the total checkouts allowed. Normally we'll just override the checkouts, but if the user also has an item with no checkouts allowed (say a reference book), staff will get this confusing message without enough information to find the problem item. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2