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

[Bug 9865] Make SIP2 message encoding configurable via SIPconfig.xml
by bugzilla-daemon＠bugs.koha-community.org 14 May '26

14 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9865 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook(a)prosentient.com.au --- Comment #21 from David Cook <dcook(a)prosentient.com.au> --- So I have an old library using 'encoding="utf8"' and I think that's actually causing double-encoding :| -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41125] New: SQL reports should allow to SET variable
by bugzilla-daemon＠bugs.koha-community.org 14 May '26

14 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41125 Bug ID: 41125 Summary: SQL reports should allow to SET variable Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com It should be nice to have the ability to define a variable with the SET operator -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 42601] New: Print barcode range needs to be limited to something reasonable
by bugzilla-daemon＠bugs.koha-community.org 13 May '26

13 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42601 Bug ID: 42601 Summary: Print barcode range needs to be limited to something reasonable Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1. Go to Cataloging > Label Maker > Print barcode range 2. To: 34335000634343 3: From: 33433500063434 34335000634343 - 33433500063434 = roughly 900 billion That's not reasonable. Koha should not try to create 900 billion labels. There should be a reasonable limit to this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 16687] New: Translatability: Fix issues in Administration preferences
by bugzilla-daemon＠bugs.koha-community.org 13 May '26

13 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16687 Bug ID: 16687 Summary: Translatability: Fix issues in Administration preferences Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Fix sentence splitting and other translation issues in file koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/admin.pref to avoid odd translations. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 45

[Bug 42599] New: Inventory tool reports items missing that are in another location
by bugzilla-daemon＠bugs.koha-community.org 13 May '26

13 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42599 Bug ID: 42599 Summary: Inventory tool reports items missing that are in another location Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: tony.z(a)swau.edu QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Our library has a number of books with copies having multiple item types (think Main and Vault, for instance.) When I scan the shelves in the Vault, I generate a barcode list, then upload it to the inventory tool, and check the "Vault" box to filter by item type, it correctly handles the ones I've scanned, but it also indicates that items out in the Main collection, but attached to the same bib record, are missing. I think the problem is that the filtering by item type works off the 942 field in the bib record, but there's only one item type there whereas multiple item records, possibly with different item types, can be attached to the same bib record. Is there a way to have the inventory tool filter on the Koha item type in the item record(s), rather than using the bib record item type? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 17705] New: Payments with cards through payment terminal
by bugzilla-daemon＠bugs.koha-community.org 13 May '26

13 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17705 Bug ID: 17705 Summary: Payments with cards through payment terminal Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: rbit(a)rbit.cz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Allow patrons to pay their fees cashlessly using cards in payment terminals. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 42597] New: Pass SSH-level timeouts to SFTP file transport
by bugzilla-daemon＠bugs.koha-community.org 13 May '26

13 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42597 Bug ID: 42597 Summary: Pass SSH-level timeouts to SFTP file transport Initiative type: --- Sponsorship --- status: 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Koha::File::Transport::SFTP constructs Net::SFTP::Foreign with timeout => DEFAULT_TIMEOUT ( currently hard coded to 10 seconds ), which only governs per-I/O reads from the underlying ssh child. It does not bound the SSH protocol handshake. When a remote sshd accepts the TCP connection but stalls during key exchange, ssh sits in tcp_recvmsg waiting for the next handshake message and the Perl parent waits with it but the module timeout never fires because no I/O is happening. It just sits forever. An strace of a process in this state looks like: select(16, [9], NULL, NULL, {tv_sec=0, tv_usec=119055}) = 0 (Timeout) wait4(59926, 0x7ffe587503e4, WNOHANG, NULL) = 0 select(16, [9], NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout) wait4(59926, 0x7ffe587503e4, WNOHANG, NULL) = 0 select(16, [9], NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout) wait4(59926, 0x7ffe587503e4, WNOHANG, NULL) = 0 select(16, [9], NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout) wait4(59926, 0x7ffe587503e4, WNOHANG, NULL) = 0 select(16, [9], NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout) wait4(59926, 0x7ffe587503e4, WNOHANG, NULL) = 0 select(16, [9], NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout) wait4(59926, 0x7ffe587503e4, WNOHANG, NULL) = 0 select(16, [9], NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout) wait4(59926, 0x7ffe587503e4, WNOHANG, NULL) = 0 select(16, [9], NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout) wait4(59926, 0x7ffe587503e4, WNOHANG, NULL) = 0 select(16, [9], NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout) wait4(59926, 0x7ffe587503e4, WNOHANG, NULL) = 0 select(16, [9], NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout) wait4(59926, 0x7ffe587503e4, WNOHANG, NULL) = 0 select(16, [9], NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout) wait4(59926, 0x7ffe587503e4, WNOHANG, NULL) = 0 select(16, [9], NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout) wait4(59926, 0x7ffe587503e4, WNOHANG, NULL) = 0 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 39631] New: longoverdue.pl does not consider OverdueNoticeCalendar when calculating overdue days
by bugzilla-daemon＠bugs.koha-community.org 13 May '26

13 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39631 Bug ID: 39631 Summary: longoverdue.pl does not consider OverdueNoticeCalendar when calculating overdue days 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: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When the system preference OverdueNoticeCalendar is activated, the script longoverdue.pl continues to calculate overdue duration using calendar days instead of working days. This creates a discrepancy with overdue_notices.pl, which correctly uses working days for triggering overdue notices when OverdueNoticeCalendar is enabled. As a result, items may be marked as lost by longoverdue.pl before the final configured overdue notice (e.g., ODUE3) has a chance to be sent. To test 1. Set the system preference OverdueNoticeCalendar to « ignore calendar » 2. Set the following preferences: DefaultLongOverdueLostValue = Long Overdue DefaultLongOverdueDays = 15 3. Define days when the library is closed 3.1. Go to Tools > Calendar 3.2. Click on a Saturday (e.g., 2025-04-12) Fill Description = Saturdays, Click on "Holiday repeated every same day of the week." and Click on Copy to all libraries and submit 3.3. Repeat step 3.2. by clicking on Sundays (e.g., 2025-04-13) similarly. 4. Checkout an item to a patron of category type Board, and set due date to 2025-03-29 (15 days before today). 4.1. Click on "Show checkouts", click the barcode, and note the itemnumber. 5. Run: ./misc/cronjobs/longoverdue.pl --> The item should be flagged as overdue (e.g., item 378 appears in the output). 6. Now Enable the system preference OverdueNoticeCalendar. 7. Run longoverdue.pl again: --> The item is still detected as overdue, even though it should not be (due to holidays). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 40096] New: Add salutation/ borrowers.title to batch patron modification
by bugzilla-daemon＠bugs.koha-community.org 13 May '26

13 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40096 Bug ID: 40096 Summary: Add salutation/ borrowers.title to batch patron modification Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: PC OS: Windows Status: NEW Severity: enhancement Priority: P1 - high Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com, sonia.bouis(a)univ-lyon3.fr CC: sonia.bouis(a)univ-lyon3.fr Salutation/ borrowers.title is an older field that libraries sometimes have data in as a result of migrated data or prior library policy, but it's not the easiest to get in and modify out once they no longer want it. It would be nice if salutation was a field in batch patron modification, either for the ability to update in bulk if a library IS using titles, or to be able to easily blank out values there if the library no longer wants them. Perhaps the field could only display if BorrowersTitles is enabled, at least until 11815 is unblocked, and then conditions could be revisited. --- Comment #1 from Sonia Bouis <sonia.bouis(a)univ-lyon3.fr> --- + 1 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 9083] Remove <<items.content>> form list of placeholders for CHECKIN/CHECKOUT notices
by bugzilla-daemon＠bugs.koha-community.org 13 May '26

13 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9083 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook(a)prosentient.com.au --- Comment #5 from David Cook <dcook(a)prosentient.com.au> --- I reckon we update the default notices and then remove it form the field selection list for sure -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0