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

[Bug 43465] New: Patrons linked to sip accounts should have a badge
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43465 Bug ID: 43465 Summary: Patrons linked to sip accounts should have a badge Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Similar to the superlibrian badge. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 43106] New: Patrons used for SIP clients should have separate permission
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43106 Bug ID: 43106 Summary: Patrons used for SIP clients should have separate permission Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- I note that there's only 1 permission currently used for SIP clients and that's the "circulate" permission as per "api_auth" called in "login_core" in C4::SIP;:Sip::MsgType. I think we could keep it backwards compatible, but it would be better I think to have an explicit "sip_client" permission, since it seems very very common that people over-permission their SIP accounts. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 40802] New: cleanup_database is broken with ChildNeedsGuarantor
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40802 Bug ID: 40802 Summary: cleanup_database is broken with ChildNeedsGuarantor Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Steps to reproduce : 1 - Have a child expired patron expired for more than the content of LockExpiredDelay syspref 2 - Set syspref to "childneedsguarantor" 3 - Run /home/koha/src/misc/cronjobs/cleanup_database.pl You will get an uncaught error -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 42728] New: Cronjob cleanup_database.pl is broken with ChildNeedsGuarantor
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42728 Bug ID: 42728 Summary: Cronjob cleanup_database.pl is broken with ChildNeedsGuarantor Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Steps to reproduce. 1 - Go to /cgi-bin/koha/members/moremember.pl?borrowernumber=37 and make sure it is a Kid without guarantor. 2 - Enable ChildNeedsGuarantor 3 - Run ./misc/cronjobs/cleanup_database.pl -v --confirm -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 35369] New: SIP default 'Greetings from Koha.' message for patrons should be optional and configurable
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35369 Bug ID: 35369 Summary: SIP default 'Greetings from Koha.' message for patrons should be optional and configurable Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be nice to have a syspref / sip configuration option to remove or customize this message without having to use regex on the AF field -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 6892] If a URL has been entered without http://, it isn't correctly linked
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6892 Hugo Agud (OREX Digital) <hagud(a)orex.es> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hagud(a)orex.es --- Comment #27 from Hugo Agud (OREX Digital) <hagud(a)orex.es> --- Tested on a community sandbox (main at f7f4ff7, MARC21, Zebra), using the demo record from attachment 204254, imported as biblionumber 439. Both patches apply cleanly with no whitespace warnings, and the sandbox QA run reports [PASS] for MARCdetail.tt and [SKIP] for MARC21slimUtils.xsl, with no failures. Staff interface, MARC view (MARCdetail.pl), the 21 $u subfields of the demo record. Before the patches, all 21 were rendered as links and 10 of them pointed at a relative URL, so they resolved to /cgi-bin/koha/catalogue/<value>: example.com (x2), someone(a)example.com (x2), locis.loc.gov (x2), ftp.gnu.org/gnu/ (x2) and 123456789 (x2). After the patches, 16 are links and 5 are plain text, and the 5 left as text are exactly the ones with no indicator. The prefixes are the expected ones: ind1=4 -> http://, ind1=0 -> mailto:, ind1=2 -> telnet://, ind1=1 -> ftp://, ind1=3 -> tel:. Values that already carried a protocol are untouched, and no relative href is left. OPAC with TrackClicks = Track: the 20 links of the 856 fields now go through tracklinks.pl with the URI already carrying its protocol, which is what the follow-up fixes. Three notes, none of them blocking. 1. The commit message says the check is "^[A-Za-z]:", a single character before the colon, which would not match "http:". The code correctly uses "^[a-zA-Z]+:". Only the message needs fixing. 2. The staff interface and the OPAC now disagree when indicator 1 is empty. The staff patch leaves those values unlinked, while the OPAC's AddMissingProtocol falls back to http:// in its <xsl:otherwise>, so with TrackClicks on the tracked URI becomes http://someone@example.com and http://123456789. That fallback is older than this patch, but the follow-up now carries it into the tracked links as well, so it may deserve a bug of its own. 3. The staff fix depends on tab0X.tag_ind, and MARCdetail.pl only sets it in one branch (lines 206-219): not when hide_marc is enabled, and not for a repeated tag when LabelMARCView is 'economical'. Measured with this record and both patches applied: with LabelMARCView = standard, 16 of the 21 subfields are linked; switching to 'economical' drops that to 12. It may be worth passing the indicators to the template independently of the display preferences. Note also that test plan step e refers to "LabelMARCView=Do", but the code compares the preference against 'economical', so that step cannot be followed as written. For the record, two things that look risky but are not: tag_ind cannot be the bare string "0", because display_marc_indicators turns blanks into "#", so an 856 with ind1=0 arrives as "0#" and the mailto: case does fire; and the OPAC change lands in the shared renderMARCOnlineResourceField template, so it also covers the results page and the 857 field, which I did not test as the demo record has none. I reviewed and signed this off myself, with AI assistance for running the test plan and cross-checking the code, as allowed by Coding Guidelines 1.8. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 6892] If a URL has been entered without http://, it isn't correctly linked
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6892 Community Sandboxes <sandboxes(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #26 from Community Sandboxes <sandboxes(a)biblibre.com> --- Signed off using a sandbox -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 6892] If a URL has been entered without http://, it isn't correctly linked
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6892 --- Comment #25 from Community Sandboxes <sandboxes(a)biblibre.com> --- Created attachment 208291 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=208291&action=e… Bug 6892: Fix links on MARCdetail.tt when protocol is missing This patch will check for URLs in MARC21 data by following the approach from details xsl template AddMissingProtocol: - when a protocol prefix is given (URI starts with "^[A-Za-z]:") the URL then gets wrapped in an html <a> element - when no protocol prefix is given it gets added based on indicator 1 of that subfield: - ind1=0 prefixed with mailto: - ind1=1 prefixed with ftp:// - ind1=2 prefixed with telnet:// - ind1=3 prefixed with tel: - ind1=4 prefixed with http:// - ind1=7 ommitted When prefix is added, the URL then gets wrapped in an html <a> element This will apply to all subfields flagged as 'is url' in MARC framework. This also fixes a small bug: the subfield code (f.e. 'u') was displayed even when sys pref hide_marc is set to Don't show Test plan: a) import demo record from listed attachments via More -> Cataloging -> Stage MARC records for import This record 1. 856 4 _u example.com 2. 856 4 _u https://example.com 3. 856 _u https://example.com 4. 856 _u example.com 5. 856 0 _u mailto:someone@example.com 6. 856 0 _u someone(a)example.com 7. 856 _u mailto:someone@example.com 8. 856 _u someone(a)example.com 9. 856 2 _u locis.loc.gov 10. 856 2 _u telnet://locis.loc.gov 11. 856 _u telnet://locis.loc.gov 12. 856 _u locis.loc.gov 13. 856 1 _u ftp.gnu.org/gnu/ 14. 856 1 _u ftp://ftp.gnu.org/gnu/ 15. 856 _u ftp://ftp.gnu.org/gnu/ 16. 856 _u ftp.gnu.org/gnu/ 17. 856 3 _u 123456789 18. 856 3 _u tel:123456789 19. 856 _u tel:123456789 20. 856 _u 123456789 21. 505 4 _u http://ftp.gnu.org/gnu/ b) open the records MARC view (MARCdetail.pl) and take a look at the links in tab 5 and 8 - check all URLs are links. - check that all URLs missing a protocol prefix (http:, ftp:, mailto:, etc) link to the ktd instance like http://KTDINSTANCE/cgi-bin/koha/catalogue/wrong_url_here - check all URLs having a protocol prefix as they will link correctly. c) apply patch and reload MARCdetail.pl (maybe a restart_all is required) - check that URLS without a protol prefix get a prefix added when an apporiate indicator is given (f.e. 1, 6, 9, 13, 17) - check that only URLs with a protocol prefix are now linked. d) when syspref hide_marc=Don't show only URLs with protocol get linked. e) with syspref LabelMARCView=Do only URLs with protocol get linked. Signed-off-by: Hugo Agud (OREX Digital) <hagud(a)orex.es> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 6892] If a URL has been entered without http://, it isn't correctly linked
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6892 --- Comment #24 from Community Sandboxes <sandboxes(a)biblibre.com> --- Created attachment 208290 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=208290&action=e… Bug 6892: (follow-up) Fix urls in OPAC when TrackClicks is enabled This patch fixes outgoing links from 856$u when system preference 'TrackClicks' is set and the URL is lacking the protocol prefix. Test plan: a) set system pref TrackClicks to 'Track' or 'Track anonymously' b) edit a record (f.e. 262) and set the following 856 fields (the record from 1st patch is sufficient though): 1. 856 ind1=4 $u = example.com 2. 856 $u = example.com 3. 856 $u = https://example.com b) save and search for that record in OPAC. c) on search results list (opac-search.pl) please check the links on that record: 1. links to http://main.localhost/cgi-bin/koha/tracklinks.pl?uri=example.com&biblionumb… and does not work 2. links to http://main.localhost/cgi-bin/koha/tracklinks.pl?uri=example.com&biblionumb… and does not work 3. links to http://main.localhost/cgi-bin/koha/tracklinks.pl?uri=https://example.com&bi… and works d) click on the record to get to the detail page (opac-detail.pl) and check the links again (Online resources). They should be the same as in step c) e) apply patch, call restart_all and redo step b) until d) verifying that 1. is now prefixed with http:// and links to http://main.localhost/cgi-bin/koha/tracklinks.pl?uri=http://example.com&bib… (works now) 2. is now prefixed with http:// and links to http://main.localhost/cgi-bin/koha/tracklinks.pl?uri=http://example.com&bib… (works now) 3. still links to http://main.localhost/cgi-bin/koha/tracklinks.pl?uri=https://example.com&bi… Signed-off-by: David Nind <david(a)davidnind.com> Signed-off-by: Hugo Agud (OREX Digital) <hagud(a)orex.es> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 6892] If a URL has been entered without http://, it isn't correctly linked
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

1 0