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

[Bug 34223] New: ILL status filter does not load immediately after selecting a backend filter
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34223 Bug ID: 34223 Summary: ILL status filter does not load immediately after selecting a backend filter Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com CC: pedro.amorim(a)ptfs-europe.com Selecting a backend filter in ILL is required in order for the status filter to become enabled. Once a provider is chosen in the backend filter, it takes the status filter around 7s to populate instead of populating immediately. This is confusing to staff members and can also disrupt the workflow. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 59

[Bug 34058] New: ILL - Left filters not considering all terms in input
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34058 Bug ID: 34058 Summary: ILL - Left filters not considering all terms in input Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, katrin.fischer(a)bsz-bw.de, magnus(a)libriotech.no, martin.renvoize(a)ptfs-europe.com, nick(a)bywatersolutions.com, pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com Depends on: 22440 To reproduce, on k-t-d: 1) Run bash <(curl -s https://raw.githubusercontent.com/ammopt/koha-ill-dev/master/start-ill-dev.…) 2) Create a FreeForm ILL request and input 23529000035676 in the cardnumber, that's "Henry Acevedo". 3) Go back to the ILL list table, input "henry" in the bottom "Patron" filter input and press the "Search" button, notice it fetches the request correctly. 4) Now do the the same search but with "henry acevedo", notice the request is not retrieved. The same issue also happens in the "keyword" filter input. Info: patron-search.inc is already doing what we need, but for patrons left side filters, it's handling all the patterns present in the #search_patron_filter input and adding each of those to the query, we need something similar here. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22440 [Bug 22440] Improve ILL page performance by moving to server side filtering -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 44

[Bug 43059] New: Remove C4::Biblio::GetMarcPrice in favor of MetadataExtractor
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43059 Bug ID: 43059 Summary: Remove C4::Biblio::GetMarcPrice in favor of MetadataExtractor Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial 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: 43058 Target Milestone: --- GetMarcPrice extracts a price from MARC fields and normalizes it via MungeMarcPrice. This is a straightforward MetadataExtractor candidate: - MARC21: 345$c, 020$c - UNIMARC: 345$d, 010$d, 071$d Callers to migrate: - acqui/addorderiso2709.pl - acqui/neworderempty.pl - Koha/MarcOrder.pm All callers pass a MARC::Record and marcflavour explicitly, making them direct fits for the extractor pattern. MungeMarcPrice (price normalization) should be inlined into the extractor method as a private helper. Steps: 1. Add get_marc_price to MARC21 and UNIMARC extractors 2. Expose as $biblio->marc_price (convenience) 3. Migrate callers 4. Remove GetMarcPrice and MungeMarcPrice from C4::Biblio Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43058 [Bug 43058] Remove C4::Items::get_hostitemnumbers_of in favor of Koha::Biblio->host_items -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 43037] New: Cannot switch from SCO to OPAC without a CSRF error
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43037 Bug ID: 43037 Summary: Cannot switch from SCO to OPAC without a CSRF error Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- To recreate: 1. SelfCheckoutByLogin set to 'Username and password' 2. In KTD, go to http://localhost:8080/cgi-bin/koha/sco/sco-main.pl 3. Log in 4. Now go back to the regular OPAC at http://localhost:8080/ 5. You'll be asked to login, use the same credentials you did in step 3 6. 403 error, if you check the logs: [WARN] Programming error - No CSRF token passed for POST http://localhost:8080/opac/opac-main.pl (referer: http://localhost:8080/) at /kohadevbox/koha/Koha/Middleware/CSRF.pm line 107. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 23988] New: When replace record with z39.50, give option on what gets pre-populated
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23988 Bug ID: 23988 Summary: When replace record with z39.50, give option on what gets pre-populated Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently in Koha, when a user chooses to replace an existing record with another record using z39.50, Koha will prepopulate the z39.50 search with Title, Author and ISBN. This search is very constrictive and it would be nice to have the option of what fields get prepopulated instead of having to manually remove the fields that the user doesn't want. Specifically, an ISBN pre-population would be ideal for a library. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 43058] New: Remove C4::Items::get_hostitemnumbers_of in favor of Koha::Biblio->host_items
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43058 Bug ID: 43058 Summary: Remove C4::Items::get_hostitemnumbers_of in favor of Koha::Biblio->host_items Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial 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: 42563 Target Milestone: --- C4::Items::get_hostitemnumbers_of duplicates logic now available via Koha::Biblio->host_items (which uses the MetadataExtractor internally, added in Bug 42563). Remaining callers to migrate: - C4/Reserves.pm - C4/ILSDI/Services.pm - reserve/request.pl - t/db_dependent/Items.t Once all callers are migrated, the function can be removed from C4::Items. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42563 [Bug 42563] Implement Koha::Biblio->host_items using MetadataExtractor -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 42610] New: Modification history and restore modifications
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42610 Bug ID: 42610 Summary: Modification history and restore modifications Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: chris.mathevet(a)inLibro.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Added a new page that displays a record’s modification history, with the ability to restore previous states. Test Plan: - Go to a record page - Edit the record (modify, add, or remove fields) - Open “Modification history” from the left navigation bar - Select a state to restore - Verify that the restore preview displays the current record and the changes that will be applied - Click “Restore” - Verify that all modified and unmodified fields are correctly preserved in the record -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 43056] New: Update message of Confirm ILL request
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43056 Bug ID: 43056 Summary: Update message of Confirm ILL request Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- The confirmation of an ILL request has some awkward language: Proceeding with this action will set this request to 'Requested'. This means that actions have been taken to request this request from a source. If you can confirm this has been done, please proceed. I propose these changes: Proceeding with this action will set the status of the request to 'Requested'. Click Confirm Request if the request has been submitted to a source. This simplifies and adds clarity to the message. (There could be further refinements....) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 43042] 500 error when receiving an order in acquisitions
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43042 Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> --- *** This bug has been marked as a duplicate of bug 42995 *** -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 41572] New: Tidy kohaTable block - members
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41572 Bug ID: 41572 Summary: Tidy kohaTable block - members Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 51