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

[Bug 42902] New: Dark-mode regression guards for the staff interface
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42902 Bug ID: 42902 Summary: Dark-mode regression guards 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 adds automated guard rails so the dark-mode work does not regress and future contributions do not re-introduce hardcoded colours in areas that have been migrated to the Koha colour tokens. This is the capstone of the dark-mode series and should be applied once the component migrations are in place (bugs 42898, 42899, 42900, 42901). Cypress (t/cypress/integration/Theme_spec.ts): Confirms the correct theme is applied before the page is interactive (no flash of the wrong theme). Round-trips Light / Dark / Auto through the switcher and a reload and checks the resolved theme on the page each time. Reads the actual computed surface/text colours and asserts they differ between light and dark, i.e. the theme really flips. Drives the header switcher UI and checks the active state follows. Loads several representative pages in each mode. Stylelint (.stylelintrc.json): A "no hardcoded hex colour" rule scoped to the migrated staff SCSS, emitted as a warning (it does not fail the build) pointing reviewers at the colour tokens. Files not yet migrated, and the files that intentionally hold the colour values, are excluded; as more areas are migrated their entries are removed and the rule starts guarding them. The OPAC is out of scope. Depends on: bug 42898, bug 42899, bug 42900, bug 42901 Test plan: 1) Apply the patch (after bugs 42898, 42899, 42900, 42901). 2) Cypress: run t/cypress/integration/Theme_spec.ts against a built instance. All assertions should pass. 3) Stylelint warns on a new hex literal: echo '.foo { color: #BADA55; }' \ > koha-tmpl/intranet-tmpl/prog/css/src/_demo.scss npx stylelint koha-tmpl/intranet-tmpl/prog/css/src/_demo.scss Expect a warning pointing at the colour tokens. Remove _demo.scss afterwards. 4) Stylelint stays quiet on an already-migrated file: npx stylelint koha-tmpl/intranet-tmpl/prog/css/src/_root.scss Expect no hex-colour warnings. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 42899] New: Dark mode for core staff interface chrome
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42899 Bug ID: 42899 Summary: Dark mode for core staff interface chrome 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 builds on the dark-mode foundation (bug 42898) by migrating the core staff-client chrome to the Koha colour tokens, so it flips with the Light/Dark/Auto theme switcher instead of staying glued to light colours. Areas covered: * Global chrome - the patron sidebar, admin/tools side menu, catalogue search facets, search results panel and summary, the sticky search header and the apply-to-results action panels. * Forms - fieldsets, legends, text/select/file inputs, read-only fields and textareas. * Tables (grid only) - cell text, the active tab and its content panel. * Toolbars - the button toolbar above lists and its dropdown menus. * Header - the search-bar autocomplete drop-down and the breadcrumb bar. * Home page - news blocks and the big icon links. Light mode is unchanged: each token's light value is the colour used today. The dark values are tuned for legible contrast. Note: status-coloured table rows (overdue, on hold, etc.) and the DataTables footer/export chrome are handled in bug 42900. Vue widgets are in bug 42901. The OPAC is out of scope. Depends on: bug 42898 Test plan: 1) Apply the patch (after bug 42898) and rebuild the CSS (yarn css:build). 2) Light mode regression. With the theme set to Light, click through: a patron record (sidebar), the admin home and a tools page (side menu), catalogue search results (facets, results, search header, apply-to-results), a patron entry form, the staff home page (news and the big icon links). Everything should look exactly as it did before this patch. 3) Dark mode. Switch the header control to Dark and revisit the same pages. Each of the areas above should now use dark surfaces with readable text, flowing into the dark page chrome rather than standing out as bright panels. Text, headings, form fields, toolbar buttons and the autocomplete drop-down should all be comfortably legible. 4) Tabs. Open a tabbed screen (e.g. a patron record). In light mode the tabs look as before; in dark mode the active tab and the panel under it should be dark and read as one piece. 5) Switch back to Light and confirm everything returns to normal. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 41251] New: Ability to edit linked serials when editing items needs to be optional
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41251 Bug ID: 41251 Summary: Ability to edit linked serials when editing items needs to be optional Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bug 37116 added the ability to edit linked serials when editing items. There is no way to turn this off and it has created some extra clicks and frustration for librarians who do not want the option. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 54

[Bug 42035] New: Add diff support to APIKEYS CREATE and DELETE action logs
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42035 Bug ID: 42035 Summary: Add diff support to APIKEYS CREATE and DELETE action logs Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Blocks: 37940 The action logging for the APIKEYS module (Koha/ApiKey.pm) already has diff support for MODIFY, REVOKE, and ACTIVATE actions. However, CREATE and DELETE actions do not pass the $original parameter. Affected calls in Koha/ApiKey.pm: - APIKEYS/CREATE (~line 84): logaction( 'APIKEYS', 'CREATE', $self->patron_id, $self, undef ); (passes $self as $infos but no $original; for CREATE, $self represents the new state) - APIKEYS/DELETE (~line 142): logaction( 'APIKEYS', 'DELETE', $patron_id ) (no info or original passed at all) For CREATE, passing $self as both $infos and $original (or with undef original) would allow the viewer to show what was created. For DELETE, the API key object should be fetched before deletion and passed as both $infos and $original so the log shows what was deleted. This is important for security audit trails. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37940 [Bug 37940] [OMNIBUS] All modification logged via action logs should include original to create JSON diff -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 22972] New: Proposal for enriching the bibliographic records with standard identifiers from authority data
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22972 Bug ID: 22972 Summary: Proposal for enriching the bibliographic records with standard identifiers from authority data Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Thinking in terms of linked data, it would be of profit to have as much of standard identifiers in the bibliographic data produced by the library as possible. Libraries use authority data coming from official sources (like LoC, SUDOC, etc.) or enrich their locally created authority records with standard identifiers (e.g. viafId, ISNI, Wikipedia). This information is linked to the bibliographic record by the Koha-specific subfield $9 which is illegal in terms of MARC 21 and does not mean anything outside of the local Koha ecosystem. A record moved out of a local Koha catalogue (downloaded, exported) loses the linked-data connection to other objects (like authors, subjects etc.), which are then identified only by strings. To make this connection between bibliographic access point and objects identified by universal identifiers more permanent outside of the local environment, the standard MARC 21 $0 subfield could be used. (UNIMARC has to be examined - $3 subfield?) The required changes would include at least: C4::AuthoritiesMarc::merge function, the authority plugin, some new system preferences, optionally display templates and also a script to update the existing biblio records. New possible system preferences needed: - switch the feature on/off - source of the standard IDs (possibly different for different biblio fields?) (standard in MARC 21 authority: 024, but may be also 010/035) (a list) - how many ids should be copied (= how may $0 added): only the first found or all of them - if an extra link/icon should be generated in display (OPAC / librarian) Please, share your comments about this idea. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 72

[Bug 39522] New: Add hooks to allow 'Valuebuilder' plugins to be installable
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39522 Bug ID: 39522 Summary: Add hooks to allow 'Valuebuilder' plugins to be installable Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: jacob.omara(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org We should allow the cataloguing or 'valuebuilder' plugins to be installable with the standard plugin architecture. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 72

[Bug 42832] New: Introduce a basic theme step to onboarding tool
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42832 Bug ID: 42832 Summary: Introduce a basic theme step to onboarding tool Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- When we set up a new small Koha there's a few common steps we'll do that make the Koha feel more like their own and work more seamlessly: - set OPACBaseURL and staffClientBaseURL system preferences - set LibraryName system preference - provide a logo or banner image URL to place on the OPAC - provide a primary colour to use for headings and links on the OPAC It would be nice if these steps could be done as part of the onboarding process -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 42807] New: Introduce profiles to onboarding tool to pre-set preferences and other settings based on type of installation
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42807 Bug ID: 42807 Summary: Introduce profiles to onboarding tool to pre-set preferences and other settings based on type of installation Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- The Koha Administration module holds hundreds of possible settings and configurations. The web installer now has an onboarding tool which sets the critical things up from the beginning - but then what? We'd like to introduce 'profiles' to the onboarding experience. Choose which type of Koha installation you are, fill in a few extra details, and a bunch of settings will get decided for you. Then you can adjust settings as needed, rather than entering into the Administration module and not knowing where to go first. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 8137] Checkout limit for all libraries
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8137 Lisette Scheer <lisette(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA QA Contact|testopia(a)bugs.koha-communit |lisette(a)bywatersolutions.co |y.org |m --- Comment #172 from Lisette Scheer <lisette(a)bywatersolutions.com> --- The warning for the checkout doesn't specify that it's from the global limit, it just looks like a matching rule from the global. The only difference on the message when the global limit is set is that it's for all libraries, but it's confusing for troubleshooting that it doesn't specify that it's the global limit. Too many checked out. 5 checked out, only 5 are allowed. Maximum checkouts calculated from the circulation rule for Item type: All item types Patron category: All patron categories Library: Centerville I tried adding another if to the list after the library: [% IF rule.has_prority == "1" %] <li> Global checkout limit </li> [% END %] But I get the following error when I try checking an item out: Template process failed: undef error - The method Koha::CirculationRule->has_prority is not covered by tests! Trace begun at /kohadevbox/koha/Koha/Object.pm line 1057 Koha::Object::AUTOLOAD('Koha::CirculationRule=HASH(0x55ecbcfd7538)') called at /kohadevbox/koha/koha-tmpl/intranet-tmpl/prog/en/modules/circ/circulation.tt line 1385 This is what gets dumped out if you dump the rule: $VAR1 = { 'rule_name' => 'maxissueqty', 'categorycode' => undef, 'branchcode' => undef, 'rule_value' => '5', 'itemtype' => undef, 'has_priority' => 1, 'id' => 54 }; This pointed out to me that we should have tests to cover this use case. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 16291] New: koha-remove --purge should also delete /etc/koha/sites/instance
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16291 Bug ID: 16291 Summary: koha-remove --purge should also delete /etc/koha/sites/instance Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: mtj(a)kohaaloha.com QA Contact: testopia(a)bugs.koha-community.org It would be useful if 'koha-remove --purge' also deleted a /etc/koha/sites/instance dir -- You are receiving this mail because: You are watching all bug changes.

1 15