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

[Bug 32059] New: How to run scripts found under https://perldoc.koha-community.org/
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32059 Bug ID: 32059 Summary: How to run scripts found under https://perldoc.koha-community.org/ Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: mik(a)adminkuhn.ch QA Contact: testopia(a)bugs.koha-community.org Documentation pages like https://perldoc.koha-community.org/misc/migration_tools/bulkmarcimport.html do not give the proper command to run the script. In the example section "Usage" says: $ export KOHA_CONF=/etc/koha.conf $ perl misc/migration_tools/bulkmarcimport.pl -d -commit 1000 -file /home/jmf/koha.mrc -n 3000 When using Debian package installation one way to actually run the program is: As user "root": # export KOHA_CONF=/etc/koha/sites/instancename/koha-conf.xml # export PERL5LIB=/usr/share/koha/lib # /usr/share/koha/bin/migration_tools/bulkmarcimport.pl -b -m marcxml -framework=frameworkname -file TITEL.marcxml -v 2 But it seems the following way is recommended: As user "koha": $ sudo koha-shell -c "/usr/share/koha/bin/migration_tools/bulkmarcimport.pl -b -m marcxml -framework=frameworkname -file TITEL.marcxml -v 2" instancename Better documentation how to run this kind of scripts would be useful. https://perldoc.koha-community.org/ shows many more such scripts. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 41305] New: Make the list of harvesting jobs more informative in erm/eusage/usage_data_providers
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41305 Bug ID: 41305 Summary: Make the list of harvesting jobs more informative in erm/eusage/usage_data_providers Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk I have not checked in main, but in 24.11 when you harvest a datasource this kind of message is displayed : "Job for report type DR has been queued. Check job progress." It could be more informative : adding the name of the source and the begin and end date could make it easier to identify a job if you want to get more information -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 42088] New: ERM usage data provider summary not usable
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42088 Bug ID: 42088 Summary: ERM usage data provider summary not usable Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: michaela.sieber(a)kit.edu QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk If you have harvested a lot of COUNTER usage data the usage data provider summery does not work any more. /cgi-bin/koha/erm/eusage/usage_data_providers/summary Error message : Something went wrong: SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 42215] New: ERM Usage Reports (Yearly) – Incorrect Data
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42215 Bug ID: 42215 Summary: ERM Usage Reports (Yearly) – Incorrect Data Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: michaela.sieber(a)kit.edu QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk Only the first row of the erm_usage_yus table is displayed, which results in incorrect data being shown. Please also refer to the related bug 42214 -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 42214] New: ERM usage database table erm_usage_yus contains incorrect data
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42214 Bug ID: 42214 Summary: ERM usage database table erm_usage_yus contains incorrect data Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: michaela.sieber(a)kit.edu QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk There is an issue with the calculation of yearly usage: the yearly totals should equal the sum of all monthly usage values, but they currently do not. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 42898] New: Dark-mode foundation and theme switcher for the staff interface
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42898 Bug ID: 42898 Summary: Dark-mode foundation and theme switcher for the staff interface Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- This patch lays the foundations for staff-client dark mode: the colour-mode machinery, a set of Koha design tokens, and a user-facing Light/Dark/Auto theme switcher in the header. It is deliberately foundations-only. Dark mode is NOT fully implemented yet - only the base surfaces flip at this stage. The component-by- component migration (forms, tables, search results, Vue widgets, etc.) lands in subsequent bugs, so the staff client will look progressively better in dark mode as those are pushed. The important thing this patch delivers is the switching mechanism and a token layer that leaves light mode untouched. What this patch adds: * A Light / Dark / Auto switcher in the staff header. "Auto" follows the operating system / browser preference; an explicit Light or Dark choice is remembered between sessions and across pages. * The chosen theme is applied before the page is drawn, so there is no flash of the wrong theme on load. If the browser blocks local storage (kiosk / privacy lockdown) the interface falls back to light mode. * A set of Koha colour tokens (--koha-surface, --koha-on-surface, --koha-border, ...) whose light values are identical to the colours used today, plus the dark values the follow-up bugs build on. Base page surfaces - fieldsets, page sections and the patron sidebar panel - already flip with the theme. Test plan: The pass/fail factor for this patch is "light mode is unchanged" and "theme switching works". How complete dark mode looks is NOT in scope here - that is tested in the follow-up bugs. 1) Apply the patch and rebuild the CSS (yarn css:build). 2) Light mode regression - the most important check. With the theme set to Light, click through the staff client (home page, a patron record, catalogue search results, a cataloguing/acquisitions form, the admin area). Everything should look exactly as it did before this patch. 3) Switching. Use the Light / Dark / Auto control in the header: - Switch to Dark. The page chrome and base panels turn dark immediately. (Some components are still light - that is expected at this stage.) - Switch back to Light. The interface returns to normal. - Move between pages and confirm the choice sticks. 4) No flash on load. With Dark selected, reload a page (or open a new one). It should appear dark straight away, with no brief flash of the light theme first. Repeat with Light selected. 5) Auto / follow-the-system. Set the theme to Auto. Set your operating system (or browser) to dark mode and reload - the staff client should be dark. Switch the OS back to light and reload - it should be light. 6) Accessibility / robustness. The switcher should be reachable and operable by keyboard, and a screen reader should announce which option is currently active. Switching themes should not produce any errors in the browser console. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 34579] New: Separate notice/message languages from installed languages
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34579 Bug ID: 34579 Summary: Separate notice/message languages from installed languages Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org This was mentioned by a Finnish library at PerlKohaCon23, and it makes a lot of sense! As far as I can see there is no previous bug for this. Currently, the list of installed languages governs which languages can be chosen as the "Preferred language for notices" for a patron, as well as the languages that notices can be translated into. This is too restrictive, and it should be possible to define a list of active/available "languages for notices", independently of the installed languages. For example, libraries in Finland, Sweden and Norway might want to be able to send out notices in one or more of the Sami languages, even though there are no translations for them (yet). I *think* we could use authorised values for this. As long as the codes in borrowers.lang and letter.lang correspond to each other, it shouldn't matter exactly *what* they are? Or am I missing something? We could also add a syspref to make it possible to choose between using the installed languages (default) and the alternative method of using the authorised values. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 43025] New: Show metadata repair warnings in the cataloguing edit form
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43025 Bug ID: 43025 Summary: Show metadata repair warnings in the cataloguing edit form 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 35104 Target Milestone: --- Bug 35104 makes Koha::Biblio::Metadata->store() recover non-XML characters and empty datafields automatically (recording what was fixed in biblio_metadata_errors), or throw Koha::Exceptions::Metadata::Invalid when a record's MARCXML cannot be saved at all. This patch surfaces that in the place cataloguers actually hit it: the cataloguing edit form. This patch: - Catches Koha::Exceptions::Metadata::Invalid on save in cataloguing/addbiblio.pl and shows a clear error instead of a raw exception, keeping the form populated so nothing is lost. - Shows a "Record saved with modifications" warning when a save succeeded but required automatic repair. - Lists any pre-existing, unresolved metadata errors when opening a record for editing, each with a quick-link to the affected field (where the field survived the repair) and a "Mark resolved" action. - Adds DELETE /api/v1/biblios/{biblio_id}/metadata/errors/{error_id} to resolve (delete) a metadata error row, used by the "Mark resolved" action. Depends on bug 35104. Test plan: 1. Apply this patch on top of bug 35104. 2. Catalogue a new record (or edit an existing one) and add a control character (e.g. paste text containing a Unit Separator, 0x1F) into a subfield value. Save the record. 3. Confirm the record saves successfully and a "Record saved with modifications" warning banner appears describing what was automatically fixed. 4. Re-open the record for editing. Confirm a "Data quality warnings" banner lists the fault, with a "Go to field" link and a "Mark resolved" button. 5. Click "Go to field" - confirm it switches to the correct tab and scrolls to the affected field. 6. Click "Mark resolved" - confirm the warning disappears immediately and does not reappear after reloading the page. 7. Save a record that cannot be repaired at all (e.g. temporarily force Koha::Biblio::Metadata::store to throw Koha::Exceptions::Metadata::Invalid, or use a MARC::File::XML error you can reproduce) - confirm a clear error message is shown and the form is redisplayed with your data intact, rather than a raw exception or a 500 error. 8. prove t/db_dependent/api/v1/biblios_metadata_errors.t Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35104 [Bug 35104] We should warn when attempting to save MARC records that contain characters invalid in XML -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 60

[Bug 27696] New: Allow choice between ISSUESLIP and ISSUEQSLIP when printing a SCO receipt
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27696 Bug ID: 27696 Summary: Allow choice between ISSUESLIP and ISSUEQSLIP when printing a SCO receipt 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some libraries like to print the issue quick slip from the SCO page, others like to print the regular issue slip here. We should allow for librarians to choose which one they'd like their patrons to get. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 30945] New: Branch specific self checkout login
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30945 Bug ID: 30945 Summary: Branch specific self checkout login Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It would be helpful if we could specify in the URL which branch the self check would be checking in/out as. So, for example, we could still have the single auto login that we already have, but we could specify the branch code in the URL, and it would switch that login to check in/out as that branch. This would be EXTREMELY helpful. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4