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

[Bug 40999] New: Tie checkout of an itemtype to a patron attribute
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '26

23 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40999 Bug ID: 40999 Summary: Tie checkout of an itemtype to a patron attribute Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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(a)bywatersolutions.com Many libraries require some variety of agreement form to be signed before patrons can borrow various itemtypes (laptops, hedge trimmers, other items that are expensive or potentially dangerous when misused). Many of these libraries define patron attributes to record whether or not a given patron has signed the relevant agreement is on file. It could be helpful to allow a library to tie an itemtype to a specific patron attribute, blocking checkout of that itemtype to any patron who does not have a "Yes" or 1 in that attribute. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 40286] New: Make C4::Auth::checkpw_internal use Koha::Patrons->find_by_identifier
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '26

23 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40286 Bug ID: 40286 Summary: Make C4::Auth::checkpw_internal use Koha::Patrons->find_by_identifier Change sponsored?: --- Product: Koha Version: Main 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 Bug 40275 introduced this method and this is the missing place for refactoring. The current tests for this method include the creation of actually conflicting patrons, matching their userid and cardnumber respectively. As making the proposed change is indeed a behavior change, I file this report in order to discuss how to handle it properly. The other use cases are clear and already covered in bug 40275. The blocker for this is bug 33905, in which we need to decide how to ensure identifier uniqueness, and then get rid of the tests. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 38757] New: Adding order from a staged file - "Some required subfields are unset"
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '26

23 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38757 Bug ID: 38757 Summary: Adding order from a staged file - "Some required subfields are unset" Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org When ordering from a staged file that contains item data, we have the option to edit or confirm the individual items on the "Select to import" tab, or import all items with identical information from the "Item information" tab. When importing individualized item data from the "Select to import" tab, clicking Save triggers an error: "Some required subfields are unset". Setting the Koha item type in the "Item information" tab fixes this error - but it shouldn't be necessary to set the item type in that tab if all items in the "Select to import" tab already have an item type specified. To replicate: 1. Go to Acquisitions and find or open a basket 2. Click Add to basket 3. Click Add from new file 4. Upload a MARC file containing item data 5. When the upload completes, click "Add to basket" 6. In the "Select to import" tab that comes up by default, check the checkbox next to one or more titles in the file --> This will expand the item data for those titles 7. Look over the item data, and confirm that all items have a homebranch, holdingbranch, and item type defined 8. Click "Save" --> An error pops up: "Some required subfields are unset" 9. Navigate to the "Item information" tab 10. Select a value for y - Koha item type 11. Click "Save" again --> The orders are imported successfully -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 36801] New: Allow un-resolving of a catalog concern
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '26

23 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36801 Bug ID: 36801 Summary: Allow un-resolving of a catalog concern Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We didn't allow for re-opening a resolved catalog concern before, but with the introduction of the update status's I think we managed to change the logic a bit and the 'Update' button now displays. This effectively allows for re-opening a resolved ticket; However, the actual ticket state isn't properly updated and should be so the new state is properly reflected in the display table and filtering options. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 21889] New: Include Staff Client entered Purchase Suggestions with System Preference maxopensuggestions
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '26

23 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21889 Bug ID: 21889 Summary: Include Staff Client entered Purchase Suggestions with System Preference maxopensuggestions Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently only Purchase Suggestions made by patrons through the OPAC are the only suggestions counted in the system preference MaxOpenSuggestions. It would be nice if this system preference also connected to the staff client, so a purchase suggestion done on the patrons account by staff alerted the staff that the patron already had the maximum number of purchase suggestion allowed. At this time, even if a patron has maxed out the number of open purchase suggestions on the OPAC, a staff member can still enter more purchase suggestions for that patron through the staff client without knowledge of the maxopensuggestions being reached. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 37645] New: Add ability to batch waive fines
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '26

23 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37645 Bug ID: 37645 Summary: Add ability to batch waive fines Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: enica(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be nice if there's an ability in Koha to waive fines/fees in a batch. This is part of a regular workflow for libraries, especially those who regularly purge patron accounts. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 80

[Bug 35325] New: Add the ERM module to Library Groups
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '26

23 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35325 Bug ID: 35325 Summary: Add the ERM module to Library Groups Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: kelly(a)bywatersolutions.com CC: jonathan.druart+koha(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 For multi-library systems in Koha currently, to use the ERM module, there is no separation to identify what agreements and licenses go to which library. It would be fantastic to add the ERM module to Library Groups to allow a way to separate and identify between libraries. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 27859] New: Marc export for search result
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '26

23 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27859 Bug ID: 27859 Summary: Marc export for search result Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: glasklas(a)gmail.com This patch provides the option of exporting a search result as MARCXML or iso 2709. Ideally the export should be asynchronous but it was much trickier than first thought to fork and detach from Apache so gave that up for now. A link to the export is sent to the current user as an email as a simple way of delivering the response asynchronously (keeping it this way so don't have to refactor when/if the export is made asynchronous). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 114

[Bug 37502] New: Holdings table needs an ERM tab
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '26

23 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37502 Bug ID: 37502 Summary: Holdings table needs an ERM tab Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org 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 If a bibliographic record is generated via an import in the ERM, the resulting bibliographic record should have an ERM tab in the holdings table. The ERM tab could have the Package and Title info, even if an item record does not exist. Similar to the Acquisitions tab for acquisitions info. -- You are receiving this mail because: You are watching all bug changes.

1 42

[Bug 42270] New: Log the date a framework changed
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '26

23 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42270 Bug ID: 42270 Summary: Log the date a framework changed Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mnero(a)oslri.net QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We would like to be able to find out when a record was changed from FA to Default. In our workflow, we overlay brief records with full ones and change the framework during import. This overlay gets logged as action "Modify" but there's no indication of a framework change, so we can't differentiate an overlay modification from any other type of modification that might happen. Ideally, we would be able to find the timestamp of when the framework was changed and by which user, but having something in the Info that indicates what the frameworkcode is/was would be useful. A solution for bug 24843 might be related. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1