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

[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 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

[Bug 37012] New: Show details of saved eUsage reports
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '25

18 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37012 Bug ID: 37012 Summary: Show details of saved eUsage reports Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com After an eUsage report has been saved, there is no way to edit it or see what has been selected as criteria when it was created. So you can only select by name, but need to have a strict naming schema or it will be hard to tell what data you are looking at. (Hope I am not missing something) -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 36887] New: Migrate "Authorized Values (BOR_NOTES)" into "Patrons (custom message)" in Notices
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '25

17 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36887 Bug ID: 36887 Summary: Migrate "Authorized Values (BOR_NOTES)" into "Patrons (custom message)" in Notices Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: caroline.cyr-la-rose(a)inlibro.com, katrin.fischer(a)bsz-bw.de, testopia(a)bugs.koha-community.org Depends on: 29393, 36717, 32986 With the introduction of custom email messages in Bug 29393, we discussed (https://chat.koha-community.org/koha-community/pl/ixoy58im47dhpr4gmwtn9sdbjw) the opportunity to merge the "Patrons (custom slip)" notice type introduced in Bug 32986 and the new "Patrons (custom message)" notice type. We could also do away with the BOR_NOTES authorized value that is currently used for the non-email notes/messages and instead combine them into the above and use a checkbox for display options (staff or opac & email) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29393 [Bug 29393] Ability to send emails from patron details page https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32986 [Bug 32986] Add ability to generate custom slips for patrons https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36717 [Bug 36717] Merge "Patrons (custom slip)" and "Patrons (custom message)" in Notices -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 39885] New: There should be a default notice to send to patrons when a new suggestion has been created by them or for them
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '25

17 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39885 Bug ID: 39885 Summary: There should be a default notice to send to patrons when a new suggestion has been created by them or for them Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org There should be a default notice ( maybe ASKED? ) that will optionally be sent when a new suggestion is created by a patron ( OPAC ) or on behalf of a patron ( staff interface ). This is not to be confused with NEW_SUGGESTION, which is sent to staff when a new suggestion is created. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 39248] New: Wrong 007/5 label for # in Nonprojected graphic
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '25

17 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39248 Bug ID: 39248 Summary: Wrong 007/5 label for # in Nonprojected graphic Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org According to https://loc.gov/marc/bibliographic/bd007k.html the label for a blank in 007/5 for Nonprojected Graphic should be "No secondary support". Currently, it sais wrongly "No attempt to code". koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/marc21_field_007.tt should be corrected. -- You are receiving this mail because: You are watching all bug changes.

1 12