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

[Bug 8937] Translation process removes CDATA in RSS XML
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '26

24 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8937 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy(a)rijksmuseum.nl --- Comment #18 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Any chance to support this by some form of testing? Note that we only have: xt/author/tt_valid.t:use C4::TTParser; If that is not reasonable given the amount of work or so, please indicate. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42370] New: locale=C breaks on the fly translations
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '26

24 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42370 Bug ID: 42370 Summary: locale=C breaks on the fly translations Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org Preparations for testing in KTD: - Install a translation, for example swedish: $ sudo koha-translate -d kohadev -i sv-SE - Enable sv-SE for OPACLanguages. - Set opaclanguagesdisplay = Allow. - Go to the OPAC. - Choose Swedish as your language. - Make sure you are not logged in. - Verify that the word for "Card number" in the login form *is* translated. To reproduce the problem set your locale to C: - $ sudo dpkg-reconfigure locales Choose to generate sv_SE.UTF-8 (for me it was option 271) When asked "Default locale for the system environment" choose the C option, for me it was 2. - $ restart_all - Go to the OPAC and refresh the front page. - Make sure you are not logged in. - Make sure your installed translation is the active language. - Verify that "Card number" in the login form is *not* translated, but the rest of the page is. This problem affects all template strings that are translated on the fly, which means they are enclosed in t(), tx(), tn() etc in the templates. For us, the solution was to change the locale on the server, so this bug report might be a "won't fix", but maybe it will be a help to future searchers. It has been suggested that it would be a good idea to change this in Koha::I18N: # LANG needs to be set to a valid locale, # otherwise LANGUAGE is ignored $ENV{LANG} = $system_locales[0]; POSIX::setlocale( LC_MESSAGES, '' ); To this: # LANG needs to be set to a valid locale, # otherwise LANGUAGE is ignored $ENV{LANG} = $system_locales[0]; setlocale(LC_MESSAGES, $locale . '.utf8'); But I have not tested that properly. Another suggestion might be to have a warning on the "About Koha" page if the locale on the server is set to C. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 41960] New: Add option to block placing hold when patron has overdues
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '26

24 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41960 Bug ID: 41960 Summary: Add option to block placing hold when patron has overdues Initiative type: --- Sponsorship --- status: 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: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Some libraries may want to block the possibility of placing hold when a patron has overdues. Currently, a patron is blocked when they has mode than maxoutstanding fines or when the account has been debarred (e.g. as a result of having overdues). But there is no possibility to directly block reserves in case of an overdue. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 40099] New: Default HOLD and HOLDDGST notices should include expiration date
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '26

24 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40099 Bug ID: 40099 Summary: Default HOLD and HOLDDGST notices should include expiration date Change sponsored?: --- Product: Koha Version: Main Hardware: PC OS: Windows Status: NEW Severity: enhancement Priority: P1 - high Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com A common adjustment to the default hold pickup notices is to include when the patron should pick them up by; especially with branches able to configure the hold expiration via circ rule, it would be nice if that was already in the default notice. Maybe even set to use KohaDate format while we're wishing here. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 40260] New: HOLDDGST doen't work for print
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '26

24 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40260 Bug ID: 40260 Summary: HOLDDGST doen't work for print Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Currently, when a patron chooses to receive digest only notification for hold filled but have no email address, Koha fall back on a print notification. This notification is using the HOLD template, and the request to receive digest is ignored. Multiple notification will be generated if multiple holds are filled. This seems due to the code around https://github.com/Koha-Community/Koha/blob/main/C4/Reserves.pm#L1929 in Koha/C4/Reserves.pm function _koha_notify_reserve #Making sure that a print notification is sent if no other transport types can be utilized. if ( !$notification_sent ) { &$send_notification( 'print', 'HOLD' ); } To reproduce : 1- Choose a borrower, make sure it has : - no email address - patron messaging prefereces : Hold filled : Email and Digests only 2-Create 2 holds for this borrower 3- Checkin document for these holds and confirm the hold each time 4- Go back to the patron page, on the Notices tab, 2 print notification are generated. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 39019] New: Do not repeat content in CHECKOUT, CHECKIN, and HOLDDGST notices when digest tags are omitted
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '26

24 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39019 Bug ID: 39019 Summary: Do not repeat content in CHECKOUT, CHECKIN, and HOLDDGST notices when digest tags are omitted Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The CHECKOUT, CHECKIN, and HOLDDGST notices assume some content will appear in the notice once, while other content will be generated per item. The content to be repeated gets wrapped in a set of dashed lines that I called "digest tags" in the bug title. Like: Hey Patron, These books got checked out: ---- [% biblio.title %] ---- While a full list of titles works well in an email, it can get prohibitively long in an SMS, so some libraries prefer a single static line for their SMS notice. However, if one fully omits those digest tags Koha will repeat the entire notice per item. If no digest tags are included in the template, Koha should not repeat any of the content on subsequent items. To recreate: 1: Edit the CHECKOUT notice to read: Test ---- ---- 2: check two items out to a patron set to receive CHECKOUT notices 3: confirm their notice says just "Test" 4: Edit the checkout notice to read: Test 5: check two items out to a different patrons set to receive CHECKOUT notices 6: confirm their notice says "TestTest" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 42462] New: Claim counts aren't updating when claims are resolved via checkin
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '26

23 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42462 Bug ID: 42462 Summary: Claim counts aren't updating when claims are resolved via checkin Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com In 25.11, claim counts on patrons' Claims tabs aren't updating when claims are resolved by checkin, both with AutoClaimReturnStatusOnCheckin set to a resolution status and with it unset (resolving claims manually on checkin). To replicate: -Set AutoClaimReturnStatusOnCheckin to any resolution status -Check out an item to any patron. -Mark the item as 'Claim returned' - note that the number on their Claims tab shows as '/1'. -Return the item - note the alert stating that the claim was resolved. -On the bib, note that the item no longer shows as claimed/lost (correct). -The patron's Claims table does not show any active claims (correct). -On the patron's Claims tab, the number of claims still shows as '/1' (incorrect - it should show as '1 0' since it's been resolved). If AutoClaimReturnStatusOnCheckin isn't set: -Check out an item to any patron. -Mark the item as 'Claim returned' - note that the number on their Claims tab shows as '/1'. -Return the item -Click 'Resolve' to resolve the claim manually. -On the bib, note that the item no longer shows as claimed (correct). -The patron's Claims table does not show any active claims (correct). -On the patron's Claims tab, the number of claims shows as '/1' (incorrect - it should show as '1 0' since it's been resolved). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 29000] New: Create a display of patrons with permissions
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '26

23 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29000 Bug ID: 29000 Summary: Create a display of patrons with permissions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Actually it is hard to find which patrons have which permissions. It can lead to mistakes and security issues. I've created a POC plugin : https://github.com/biblibre/koha-plugin-users-with-permissions Maybe permissions could be displayed in patrons search table. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 42362] New: Sorting suggestions by branch always puts the user on the first tab
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '26

23 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42362 Bug ID: 42362 Summary: Sorting suggestions by branch always puts the user on the first tab Initiative type: --- Sponsorship --- status: 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1. Have some suggestions for multiple branches. 2. Make those suggestions have various statuses ( Accepted, Rejected, etc. ) 3. Be on any tab that is not the first one. i.e Rejected 4. Sort by a different branch of 'Any'. Viewing suggestions for library: 5. You are placed back on the first tab. This is an annoyance for staff working with many suggestions. It would be nice if the active went back to the one your were working with before sorting by branch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 42460] New: When searching an item "Other holdings" tab will not show
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '26

23 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42460 Bug ID: 42460 Summary: When searching an item "Other holdings" tab will not show Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: dani(a)napleslib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Created attachment 198101 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198101&action=e… Can not get to the Other Holdings table Something went wrong when loading the table. 500: error. Have a look at the 'Audit' button in the toolbar. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1