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

[Bug 33729] New: Add a column for dateaccessioned to item search results
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '25

25 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33729 Bug ID: 33729 Summary: Add a column for dateaccessioned to item search results Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It would be useful to add a column for dateaccessioned to item search results -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 55

[Bug 36871] New: DefaultHoldPickupLocation = logged in library on multi-holds
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '25

25 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36871 Bug ID: 36871 Summary: DefaultHoldPickupLocation = logged in library on multi-holds Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If DefaultHoldPickupLocation is set to logged in library, this should be taken into account when placing multi-holds. To recreate: 0. Make sure the DefaultHoldPickupLocation system preference is set to logged in library. 1. In the staff interface, search the catalog with a term that will return a couple of items (e.g. Shakespeare) 2. In the search results, select two or more results 3. Click Place hold 4. Search for a patron (e.g. Acevedo) --> "Pickup at" and "Pickup location" are empty and the staff member must select the library -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 39067] New: Problem creating stickers with text
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '25

25 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39067 Bug ID: 39067 Summary: Problem creating stickers with text Change sponsored?: --- Product: Koha Version: 24.11 Hardware: HP OS: Linux Status: NEW Severity: major Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: sergeinik(a)tut.by QA Contact: testopia(a)bugs.koha-community.org If you create a sticker with a barcode and add numeric values to it, such as isbn, then there are no problems when generating a pdf. But if you include text data in the sticker, such as title or author, then when generating a pdf you get a zero size and no data. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 25260] New: Add a new 'holds' table
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '25

25 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25260 Bug ID: 25260 Summary: Add a new 'holds' table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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 Reengineering the current 'reserves' and 'old_reserves' tables, we propose to introduce a new table, following our current agreements on the design and addressing or use cases. An RFC will be submitted and linked here. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 174

[Bug 30648] New: Title is lost in Holds History when biblio is deleted
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '25

24 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30648 Bug ID: 30648 Summary: Title is lost in Holds History when biblio is deleted 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The patron hold history page shows "No title" for old holds on records that have since been deleted. We should get the title from deletedbibios if possible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 58

[Bug 36302] New: Patron search from search bar broken
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '25

24 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36302 Bug ID: 36302 Summary: Patron search from search bar broken Change sponsored?: --- Product: Koha Version: master 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 The patron search from the top bar has broken recently. Search for Henry in ktd from the top bar, autocomplete works, but hitting return returns zero results (and doesn't redirect to the Henry user either any more) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 95

[Bug 36345] New: Deleting related things causes data loss for old_reserves
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '25

23 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36345 Bug ID: 36345 Summary: Deleting related things causes data loss for old_reserves Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The old_reserves table is meant to be a historical preservation of data. Currently it has foreign keys a number of tables where that also have a delete/old table for preservation. For example, we may have an "old reserve" with an associated item. When we delete that item, the item is moved to the deleteditems, and old_reserves.itemnumber is set to NULL thus losing the associated item even though we still have the item data! This is true for borrowers, bibs and items. To enable saving this data, we should add a non FK column for each related table that has a delete/old version of that table. Then, when the associated item is deleted, copy the FK value to the new column before is is nullified. In fact, if we populated those columns when moving the hold from reserves to old_reserves, we wouldn't even have to add code to each of the delete methods! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 32307] New: Chocolat image viewer broken in the staff interface
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '25

23 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32307 Bug ID: 32307 Summary: Chocolat image viewer broken in the staff interface Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org I'm seeing errors in the console when viewing a bibliographic record in the staff interface. Looking at a record with more than one cover image available (e.g. Amazon and Coce) I can click the cover and see the first image in the Chocolat viewer, but there is an error in the console: Uncaught (in promise) <img src="null"> chocolat_22.0600032.js:54:19 When I click the arrow to view the next cover, the cover doesn't load. It appears to fail on the *last* image. If my record has three covers available (e.g. Local, Amazon, and Coce) the first and second images are displayed correctly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 37600] New: OpacSuppression does not work in Unimarc
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '25

23 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37600 Bug ID: 37600 Summary: OpacSuppression does not work in Unimarc Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: Igor.A.Sychev(a)mail.ru QA Contact: testopia(a)bugs.koha-community.org OpacSuppression does not work in Unimarc. If I understood correctly, need to add <index_subfields tag="955" subfields="n"> <target_index>Suppress:w</target_index> <target_index>Suppress:n</target_index> </index_subfields> in https://git.koha-community.org/Koha-community/Koha/src/branch/main/etc/zebr… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 40001] New: edit_items permission allows deletion of individual items. Should be separate.
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '25

23 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40001 Bug ID: 40001 Summary: edit_items permission allows deletion of individual items. Should be separate. Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: hananmustafaawan(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently, the edit_items permission allows a user to delete individual items using the "Action" button on the edit item page. This behavior persists even when the user does not have the delete_all_items permission, which is intended (according to documentation) to manage bulk deletion. This creates a permissions flaw: staff with rights to edit items can also delete items, which may not always be desirable from a library’s operational or security perspective. Steps to Reproduce: Create a staff account with only the edit_items permission (without delete_all_items) Go to: catalogue/itemsearch.pl Edit an item (via cataloguing/additem.pl?op=edititem&...) Click the Action button, then Delete the item The item is deleted successfully — despite lacking delete_all_items permission Expected Behavior: There should be a separate delete_items permission for deleting individual items OR Deleting any item (individual or bulk) should require the delete_all_items permission. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4