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

[Bug 42689] New: How to handle English ILL status names in translation?
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42689 Bug ID: 42689 Summary: How to handle English ILL status names in translation? Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: caroline.cyr-la-rose(a)inlibro.com, f.demians(a)tamil.fr, jonathan.druart(a)gmail.com, julian.maurice(a)biblibre.com Depends on: 37762 While translating the new strings from bug 37762 in main I noticed that often status are mentioned that look like codes. I am not sure if they should be translated and how to best handle them in translations to make the purpose clear to users. If they are codes that should not be translated some context might be helpful or maybe some should be re-worded? Collecting here to get some guidance/ideas. The supplying library cannot fill the request based on information provided or may be able to supply at a later date. Additional information is provided in the RetryInfo section. The requesting library may submit a Retry request which may include updated information koha-tmpl/intranet-tmpl/prog/js/vue/components/ILL/SupplyingResource.vue:255 CopyOrLoan koha-tmpl/intranet-tmpl/prog/js/vue/components/ILL/SupplyingResource.vue:532 • koha-tmpl/intranet-tmpl/prog/js/vue/components/ILL/SupplyingResource.vue:1089 The supplying library cannot fill the request. The explanation may be provided in the ReasonUnfilled data element koha-tmpl/intranet-tmpl/prog/js/vue/components/ILL/SupplyingResource.vue:559 Update this request's status to <strong>WillSupply </strong>? koha-tmpl/intranet-tmpl/prog/js/vue/components/ILL/SupplyingResource.vue:205 The supplying library cannot fill the request. The explanation may be provided in the ReasonUnfilled data element koha-tmpl/intranet-tmpl/prog/js/vue/components/ILL/SupplyingResource.vue:559 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37762 [Bug 37762] Expand ILL to allow for supplying agency/lending library workflows -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 14806] Action Log for Modifying borrower messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14806 hebah(a)bywatersolutions.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emily.lamancusa@montgomeryc | |ountymd.gov --- Comment #16 from hebah(a)bywatersolutions.com --- *** Bug 42470 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42470] New: Changes to patron messaging preferences should be logged
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42470 Bug ID: 42470 Summary: Changes to patron messaging preferences should be logged Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com When troubleshooting account notification issues, it would be really helpful to have action logs on any changes to patron messaging preferences. This would allow you to see if a patron's preferences have changed recently and easily identify which notifications a patron should have been receiving at a given point in time. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 14806] Action Log for Modifying borrower messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14806 Danielle M. <dmeininger591(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dmeininger591(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43628] New: Returning a lost item may not charge overdue fine when item has historical LOST overdue from another patron
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43628 Bug ID: 43628 Summary: Returning a lost item may not charge overdue fine when item has historical LOST overdue from another patron Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- When lostreturn = charge, returning a lost item should calculate and charge the patron an overdue fine. However, if the same item has a historical OVERDUE accountline with status = LOST belonging to a previous patron, Koha may use that previous patron when processing the current lost-item return. The current patron's LOST and PROCESSING charges are refunded correctly, but the new overdue fine is not created. This has been reproduced with two patrons using the same item across separate checkout/lost/return cycles. Relevant configuration --CalculateFinesOnReturn = 1 --CalculateFinesOnBackdate = 1 --WhenLostForgiveFine = 1 --BlockReturnOfLostItems = 0 --lostreturn = charge --processingreturn = refund --Fine = 0.25 --Overdue fines cap = 5.00 Steps to reproduce 1. Create Patron A and Patron B. 2. Check an item out to Patron A with a due date sufficiently in the past to generate an overdue fine. 3. Generate the overdue fine for Patron A. 4. Mark the item lost. 5. Confirm Patron A's OVERDUE accountline is now: - status = LOST - amountoutstanding = 0 6. Return the item. 7. Confirm the historical OVERDUE / LOST accountline remains associated with the item. 8. Check the same item out to Patron B with a due date in the past. 9. Do not generate an overdue accountline for Patron B before marking the item lost. 10. Mark the item lost so LOST and PROCESSING charges are created for Patron B. 11. Return the item. Expected result: The current LOST and PROCESSING charges are refunded and Patron B receives the appropriate overdue charge according to the circulation rules. For example: LOST_FOUND -10.00 PROCESSING_FOUND -5.00 OVERDUE 5.00 RETURNED Actual result: The LOST and PROCESSING charges are refunded: LOST_FOUND -10.00 PROCESSING_FOUND -5.00 but no new OVERDUE accountline is created for Patron B. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 30271] New: Allow distinct ILLHiddenRequestStatuses config for view from patron record
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30271 Bug ID: 30271 Summary: Allow distinct ILLHiddenRequestStatuses config for view from patron record 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: andrew(a)bywatersolutions.com The system preference ILLHiddenRequestStatuses is great for hiding completed ILL requests from the main ILL request page (/cgi-bin/koha/ill/ill-requests.pl). It also applies to the view of ILL requests within a patron record (/cgi-bin/koha/members/ill-requests.pl). It'd be helpful if those two views could have distinct settings so one could easily hide completed requests from the full view but see them in a specific patron's history. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 43627] New: Add ability to specify lending limits for supplying agency ILL
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43627 Bug ID: 43627 Summary: Add ability to specify lending limits for supplying agency ILL Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- Libraries should be able to specify per borrowing institution limits, i.e. what item types, lost statuses, etc prevent the hold from being available. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42804] New: Replace svc/cover_images and tools/upload-cover-image.pl with REST API
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42804 Bug ID: 42804 Summary: Replace svc/cover_images and tools/upload-cover-image.pl with REST API Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Depends on: 42404, 42405 Blocks: 42643 Target Milestone: --- The old CGI-based cover image upload (tools/upload-cover-image.pl) and delete (svc/cover_images) endpoints need to be replaced with the new REST API endpoints introduced in bugs 42404 and 42405. This involves: 1. Create a CoverImageAPIClient (fetch-based) to encapsulate the API calls 2. Rewrite upload-images.js to POST to /api/v1/biblios/{biblio_id}/cover_images (single) or /api/v1/cover_images/batch (zip) 3. Replace svc/cover_images delete calls with DELETE /api/v1/cover_images/{image_id} 4. Add background job progress polling reusing existing Koha job progress components 5. Update upload-images.tt to remove CGI form actions 6. Remove tools/upload-cover-image.pl once no longer referenced The JS work should reuse the existing background job progress UI components where possible. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42404 [Bug 42404] Add a batch cover images upload endpoint https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42405 [Bug 42405] Add single cover image upload path https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42643 [Bug 42643] [OMNIBUS] Assorted performance and stability work -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 39943] New: Add a separate PIN code field for accessing self service devices
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39943 Bug ID: 39943 Summary: Add a separate PIN code field for accessing self service devices Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Some libraries allow their patrons to authenticate to a self-checkout or an access control device with a short pin number. While this is user-friendly and compatible with numpad devices, from a security standpoint it is not acceptable to have such a weak pin code as the patron account password outside library premises in OPAC on the public internet. It would be useful to separate a weaker PIN code field from the borrowers.password field. This weaker PIN code would only be used for SIP2 and possibly SCO/SCI access in a more restricted environment. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 83

[Bug 33193] New: Book cover image visibility depends on the order of 856 fields
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33193 Bug ID: 33193 Summary: Book cover image visibility depends on the order of 856 fields Change sponsored?: --- Product: Koha Version: 22.11 Hardware: PC OS: Windows Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: tuomas.kunttu(a)kouvola.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Book cover link is in Marc field 856 and book description link is in another 856 field. Whether the book cover image is visible depends on the order in which the data is catalogued. Test: 1. System preferences: CustomCoverImages: display and CustomCoverImagesURL: {856$u} 2. Catalogue following data to a record: 856 42 u https://sopimusasiakkaat.booky.fi/description.php?ean=9789518734263 q text z Description 856 42 u https://sopimusasiakkaat.booky.fi/image.php?size=medium&id=9789518734263 q image z Cover image 3. Save and view record 4. Book cover is not visible in record's normal view nor in search results list. 5. Change the order of 856 fields: 856 42 u https://sopimusasiakkaat.booky.fi/image.php?size=medium&id=9789518734263 q image z Cover image 856 42 u https://sopimusasiakkaat.booky.fi/description.php?ean=9789518734263 q text z Description 6. Save and view record 7. Book cover is visible in record's normal view and in search results list. Book cover image should be visible regardless of the order in which the 856 fields are catalogued. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6