- 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 39917] New: Display a prompt for status alias when completing a request
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39917 Bug ID: 39917 Summary: Display a prompt for status alias when completing a request Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: pedro.amorim(a)openfifth.co.uk Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 43066] New: Incorrect processing of patron import file from web interface
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43066 Bug ID: 43066 Summary: Incorrect processing of patron import file from web interface Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: bernard.scaife(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Created attachment 201907 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201907&action=e… 3 record test patron load csv Patron import should not attempt to import header line and counts are then wrong 1. Go to import patrons tool in Koha 2. Choose attached test csv which has a header and four records NB/ You may need to adjust the branch and category code to match your system first 3. Click import 4. Import results say: 3 imported records 1 overwritten records 0 not imported because they are already in borrowers table and overwrite is disabled 1 not imported because they are not in the expected format 5 records parsed 5. Note errors shown: Error analysis Line 3 Critical field "categorycode" has unrecognized value "categorycode" (borrowernumber: UNDEF; surname: surname). cardnumber,firstname,surname,email,branchcode,categorycode,borrowernotes,userid,patron_attributes Line 3 Critical field "branchcode" has unrecognized value "branchcode" (borrowernumber: UNDEF; surname: surname). cardnumber,firstname,surname,email,branchcode,categorycode,borrowernotes,userid,patron_attributes It is trying to import the header row and should not be. 6. ftp the same csv file to the server 7. On the server, run /usr/share/koha/bin/import_patrons.pl --file /kohadevbox/koha/<testfilename> --matchpoint cardnumber --overwrite --verbose --verbose --confirm Import complete: Imported: 0 Overwritten: 3 Skipped: 0 Invalid: 0 Total: 3 Errors: $VAR1 = []; No errors, so the backend version is correct but not the staff interface -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 42322] New: Collapse sidebar
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42322 Bug ID: 42322 Summary: Collapse sidebar Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement 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 On bug 42190 we discuss the possibility to collapse the sidebar in order to enlarge the screen and specifically the table in the main div. It would be good to have the behaviour available everywhere, not only on the report result view. -- You are receiving this mail because: You are watching all bug changes.

1 127

[Bug 42868] New: Bookings are storing incorrect timezone values
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42868 Bug ID: 42868 Summary: Bookings are storing incorrect timezone values Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Staff interface 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 Target Milestone: --- Somehow, between the date picker and the DB, the bookings module is converting dates incorrectly and setting the wrong dates. To recreate: 1 - Edit koha-conf.xml 2 - Set timezone: <timezone>America/New_York</timezone> 3 - In Koha, enable bookings syspref 4 - Find a record, click the items tab, make an item bookable 5 - Place new booking, choose a date range 6 - View the bookings tab - note the booking extends into the date before 7- Check the DB: MariaDB [koha_kohadev]> select * from bookings WHERE booking_id=2; +------------+-----------+-----------+---------+-------------------+---------------------+---------------------+---------------------+---------------------+--------+---------------------+ | booking_id | patron_id | biblio_id | item_id | pickup_library_id | start_date | end_date | creation_date | modification_date | status | cancellation_reason | +------------+-----------+-----------+---------+-------------------+---------------------+---------------------+---------------------+---------------------+--------+---------------------+ | 2 | 12 | 437 | 971 | FPL | 2026-06-23 20:00:00 | 2026-06-26 19:59:59 | 2026-06-17 15:00:40 | 2026-06-17 15:00:40 | new | NULL | +------------+-----------+-----------+---------+-------------------+---------------------+---------------------+---------------------+---------------------+--------+---------------------+ 1 row in set (0.000 sec) Start date time is 20:00 - really 00:00 minus 4 - New York is UTC minus 4 - it seems we shouldn't subtract more -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 34814] New: Limiting item editing to library or library group disables choosing items from record's details page
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34814 Bug ID: 34814 Summary: Limiting item editing to library or library group disables choosing items from record's details page Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: major Priority: P4 Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 20256 Bug 20256 adds the ability to limit editing items per library or library group. I noticed that if you are limiting the editing per library group you lose the ability to choose items on record details page. This is enabled in StaffDetailItemSelection. You cannot choose your own items either. It would be ok not to choose items that you cannot edit/delete but if you cannot choose your own items it is a big disadvantage. You cannot choose multiple items and do batch edits or deletes to them from details page. I tested the feature in PTFS Europe's sandbox (v. 23.06). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20256 [Bug 20256] Add ability to limit editing of items to home library or library group -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[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 34632] New: Patron Importing should be a background job
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34632 Bug ID: 34632 Summary: Patron Importing should be a background job 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: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hi friends, Now that we have a lovely queue for our background jobs, we should make the patron import use the queue to process those and store the outcome. This will help us avoid the 500/600/whatever you set apache timeouts experienced by libraries whenever they import batches of patrons of any significant size. Cheers, Liz -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 45

[Bug 36271] New: Bookings should respect circulation rules for max loan periods
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36271 Bug ID: 36271 Summary: Bookings should respect circulation rules for max loan periods 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently, bookings are on/off at the item level, but the booking period is entirely open meaning an item can be booked for any period. We should refine this to allow libraries to control the maximum length an item can be booked for. During the original development, I suggested perhaps we should set the maximum to the loan length of the item times the max renewals from the circulation rules.. However, I didn't get much feedback as to whether this was appropriate or whether people wanted a distinct rule for these items or another alternative. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 72