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

[Bug 40235] New: You cannot see the holds affecting borrower's checkouts, if the borrower has restrictions
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '25

19 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40235 Bug ID: 40235 Summary: You cannot see the holds affecting borrower's checkouts, if the borrower has restrictions Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: inkeri.hakulinen+bugz(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If the borrower has restrictions on their account, you cannot see the holds that affect borrower's checkouts. Usually you see from the staff interface, if there are any holds towards borrower's checkouts, and they prevent renewals. However, if a borrower has some restrictions, you cannot see the holds. Koha only shows that renewal is impossible because of the restriction. Affecting holds would be important information, when you discuss with the borrower about their situation and what they have to do to lift the restrictions. To demonstrate the problem: 1. Create borrowers A and B 2. Check out some items (i,j) to borrower A. 3. Place a hold for the item i by borrower B. 4. See from check-outs of borrower A, that you can see that the item i cannot be renewed, since there's a hold for that item. The item j is possible to renew. 5. Create a restriction for the borrower A. 6. See the check-outs of borrower A, and notice that all the checkouts seem the same. none of them are seen as renewable. Further, you can try to "override renewal restrictions". Then you can see that all the checked-out items now have a checkbox for renewal. If you actually do try to renew those, the one on hold says "Renew failed: on hold". So that actually works as it should, but you just don't see the situation beforehand. In cases of restrictions, it would be good to be able to tell the borrower about the possible holds. Otherwise you might have a situation, where borrower comes again, settles the cause that was the reason for the restriction, restriction is remowed, and only after that the borrower (and staff) finds out that all the check-outs cannot be actually renewed, because of the holds. So I propose that even in cases of borrower having restrictions, the holds that affect their checkouts would be visible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 37230] New: Add ability to define arbitrary statuses for items in Z3950
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '25

18 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37230 Bug ID: 37230 Summary: Add ability to define arbitrary statuses for items in Z3950 Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bug 36996 adds the ability to define a not-available status for items in Z3950 based on several criteria It would be nice to extend the use of YAML here to allow for defining several different statuses for different criteria -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 36996] New: Add a system preference to determine Z3950 availability
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '25

18 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36996 Bug ID: 36996 Summary: Add a system preference to determine Z3950 availability Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Some libraries would like to use additional item fields for determining if an item is available when showing z3950 results. This bug is to add a new system preference to determine availability (yes|no) via a YAML system preference - similar to OPacHiddenItems -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29

[Bug 29509] New: GET /patrons* routes permissions excessive
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '25

18 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29509 Bug ID: 29509 Summary: GET /patrons* routes permissions excessive Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com The routes require full borrowers permissions, and that's not the case for Koha, generally. If required permissions were to be lowered, bug 29503 should be pushed first. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 71

[Bug 13888] 'Lists' permission should allow/disallow using the lists module in staff
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '25

18 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13888 Caroline Cyr La Rose <caroline.cyr-la-rose(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Documentation| |Caroline Cyr La Rose contact| | Status|Needs documenting |RESOLVED Documentation| |https://gitlab.com/koha-com submission| |munity/koha-manual/-/merge_ | |requests/1107 Resolution|--- |FIXED --- Comment #34 from Caroline Cyr La Rose <caroline.cyr-la-rose(a)inlibro.com> --- I documented what I understood, but I don't know how usable this is IRL. I guess other bugs will be create as users use the features. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 40821] New: Cover image column width in OPAC search results varies
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '25

18 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40821 Bug ID: 40821 Summary: Cover image column width in OPAC search results varies 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org When the results have short titles (e.g. a search for "garden" in ktd) the image column is really wide. When the results have longer titles, the image column is narrower. Note: the cover image used to be on the right, and didn't really change position depending on the size of the title. To recreate: 1. Enable OPACAmazonCoverImages 2. Go to the OPAC and search for various terms - search term "garden": the titles are short, the image column is really wide - search term "poetry" : on long title, the image column is a nice size (same margin on each side of the image) - search term "design" : some of the titles are really long, the image column is very narrow (not the same margin on each side of the image) -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 37141] New: Add option to display completed bookings from patron page
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '25

18 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37141 Bug ID: 37141 Summary: Add option to display completed bookings from patron page 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently on the bookings tab of the patron pages, we always filter to active bookings. We should add the option to display completed bookings too; This would match the functionality introduced in the biblio details view for bookings in bug 37065 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 37574] New: Add visual indicator that bookings are expired
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '25

18 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37574 Bug ID: 37574 Summary: Add visual indicator that bookings are expired Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement 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 We should add a text and possibly a color to highlight expired bookings when displayed to make it more obvious. Bug 37141 will display expired bookings by default on a patron with no active bookings, the filter button does say 'Hide expired' but making the rows more obviously expired would be nice -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 38602] New: Columns bookings.creation_date and bookings.modification_date not added if multiple databases are in use
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '25

18 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38602 Bug ID: 38602 Summary: Columns bookings.creation_date and bookings.modification_date not added if multiple databases are in use Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org I have multiple databases in use for different versions of Koha and two of them are for Kohas current main version. One smaller one (database A) for running tests and other larger one (database B) to test e.g. loading times with large datasets. I updated both of them when version 24.11 was released. Today I tried to test some patches with database B and while checking out items, following error occured: >DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Unknown column 'me.creation_date' in 'field list' at ../Koha/Koha/Objects.pm line 321 I searched for the column creation_date from my databases and only database A has it in bookings table. I then tried to revert my database B's version back to 24.05 and run updatedatabase.pl to it again. Update printed following: >Upgrade to 24.06.00.029 [12:07:54]: Bug 37592 - Add creation_date, modification_date fields to bookings table >Columns 'creation_date' and 'modification_date' already exist in 'bookings' table. Skipping... In db_rev file 240600029.pl we determine if these columns are already in database by searching them from information_schema.COLUMNS. In environments with multiple databases (we have over 30 of them) in use this means that if one of the databases already has both these columns, adding them to other databases is skipped. We should instead check if both of those columns exist with method column_exists, not from information_schema. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 39187] New: Hold expiration date should not be extended if set by staff before hold is filled
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '25

18 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39187 Bug ID: 39187 Summary: Hold expiration date should not be extended if set by staff before hold is filled Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 Koha respects a patron's set expiration for a hold when filling, and does not extend past the original date. When a staff member places a hold for a patron the patron_expiration_date field is set. If a staff member places a hold with no expiration, then sets the expiration before the hold has been filled, the expiration date will always be replaced by the default date from ReservesMaxPickupDelay We should only replace the date if the new one is sooner. To recreate: 1 - Place a hold in staff interface with no expiration date 2 - Edit the hold expiration date to be tomorrow 3 - Set ReservesMaxPickupDelay to 7 4 - Check in the item and confirm hold 5 - Expiration date is now 7 days away -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6