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

[Bug 27572] New: Should OpacLocationBranchToDisplay be replaced by table settings?
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '25

14 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27572 Bug ID: 27572 Summary: Should OpacLocationBranchToDisplay be replaced by table settings? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The OpacLocationBranchToDisplay system preference essentially serves the purpose of hiding or showing columns in the items table in the record details page on the OPAC, namely the home library column and the current library column. Since we now have Administration > Table settings that we can use to show or hide columns, is this system preference still useful? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 35659] New: OAI Harvester
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '25

14 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35659 Bug ID: 35659 Summary: OAI Harvester Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Koha needs to be able to harvest records from OAI-PMH repositories. This patch implements a cronjob-based OAI harvester, deliberately kept simple and consistent in its configuration with what we already have in Koha for other data sources, such as Z3950 and SRU. It is sponsored by KohaLa, its goals and implementation have been previously discussed on the koha and koha-devel mailing-lists, as well as in a presentation at KohaCon'23 in Helsinki: "Let's add an OAI-PMH harvester in Koha" by Sonia Bouis. Some of the code and ideas are based on a previous implementation of an OAI harvester by David Cook (See BZ 25905 and 10662). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 214

[Bug 40606] New: Remove parentheses and italics from shelving location in the staff interface
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '25

14 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40606 Bug ID: 40606 Summary: Remove parentheses and italics from shelving location in the staff interface Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Now that bug 15461 is in Koha, I noticed that even though the shelving location was moved to its own column, the formatting and parentheses were left. That looks weird now that it's in its own colum. To recreate : 1. Go to a detailed record (make sure it has an item and the item has a shelving location, I used http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=161 --> Note that the shelving location is in parentheses and in italics I noticed that some records show the location without the parentheses already, I'm not sure why some have parentheses and some don't. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 38042] New: Wrong values in Item type form on acqui/neworderempty.pl
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '25

13 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38042 Bug ID: 38042 Summary: Wrong values in Item type form on acqui/neworderempty.pl Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Not sure of the right component for this problem, but it has an impact on our acquisition workflow. The problem seems to have been introduced by https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29554 When entering a manual order, the form on acqui/neworderempty.pl imposes a "Item type" field with a drop-down menu containing wrong values. Our configuration (defined with our vendor 2 years ago, and everything was fine in 21.11) : - UNIMARC - item-level_itypes : specific item - record level item type defined in 099$t : mapped with biblioitems.itemtype ; using TYPEDOC authorized values - item item type defined in 995$r : mapped with items.itype ; using value:itemtypes authorized values When you create a record in acqui/neworderempty.pl, the "Item type" fills the 099$t, so the form must display the TYPEDOC values. It was the (logical) behavior before the change introduced by https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29554 Now, the form display the "itemtypes" values. That's not good, it creates a data coherence issue -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 35812] New: Should specify canonical URLs to help search indexers
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '25

13 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35812 Bug ID: 35812 Summary: Should specify canonical URLs to help search indexers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: schodkowy.omegi-0r(a)icloud.com QA Contact: testopia(a)bugs.koha-community.org So we've recently added our Koha site to Google Search Console and became bombarded by its complains about lack of defined canonical URLs for pages. This is mostly a problem for bib details page. For main page, you can have three possible URLs that will all load main page: - / - /index.html - /cgi-bin/koha/opac-main.pl I think "/" should be specified as canonical URL, which could even "lazily" be achieved by following Apache directives (these will append the Link header to all three URLs above and nothing else) (they could be added to debian/templates/apache-shared-opac.conf): Header always append "Link" "</>; rel=canonical" "expr=%{REQUEST_URI} == '/index.html'" Header always append "Link" "</>; rel=canonical" "expr=%{REQUEST_URI} == '/cgi-bin/koha/opac-main.pl'" The situation gets a bit more complicated with bibs, because trying to solve it with Apache directives becomes complex if even possible, instead of another solution (note that we can also have a HTML tag instead of HTTP header). Koha links to pages with URLs in the format `/cgi-bin/koha/opac-detail.pl?biblionumber=1234`, but the Apache config has defined nice links in the format of `/bib/1234`. With `opac-detail.pl` page you get some junky parameters appeared after you reach the page from Koha search such as: - /cgi-bin/koha/opac-detail.pl?biblionumber=1234 - /cgi-bin/koha/opac-detail.pl?biblionumber=1234&query_desc=se,phr:"Something" - /cgi-bin/koha/opac-detail.pl?biblionumber=1234&query_desc=an:3200 - /cgi-bin/koha/opac-detail.pl?biblionumber=1234&query_desc=an:1846 and su-to:Something and itype:BK and su-to:Environment and su-to:Environment - /cgi-bin/koha/opac-detail.pl?biblionumber=1234&fbclid=FSD8ufs98jf39jfes80jfds8jfsd - /cgi-bin/koha/opac-detail.pl?bib=1234 To top it off, if you do a search and there's only one search result, you get redirected directly to opac-detail, confusing Google even further (I actually think it's worthy of a separate bug to add some kind of notice that you were redirected cause there was only one result, but that's a matter for another discussion...). So the solution there would also be to specify the canonical link as "/bib/1234" with no params, but I think it might be best off done in code rather than Apache config there. The end result of these would be that search results would have nice links, without weird params such as query_desc added to the indexed pages, which is awful (as the user coming from search has nothing to do with that query as when it was indexed). This would solve also another potential problem, in that such silent redirect from search results could make a search engine think that the search URL is the canonical URL (as when it's not specified, it's up to the search engine to detect duplicate and decide, but it can do so wrongly and against its own rules sometimes, as we've observed). And finally, the search URLs could also be made canonical from "/cgi-bin/koha/opac-search.pl" to "/search", however this time with keeping all URL query parameters. All of this is somewhat related to Bug 18410, but not blocked by it by any means, as the URL aliases I've described above are actually in the Apache config already for a long time, and don't depend on overall Koha routing overhaul. Btw: it's better to use full OPAC base URL instead of just "/" if we can, this will help with deduplicating indexed URLs in case your Koha is available under multiple aliased domains or is under process of changing domains (or is technically available under both http and https without a redirect, and search treats those as separate sites!). But doing so requires pure code solution instead of Apache directives. -- You are receiving this mail because: You are watching all bug changes.

1 38

[Bug 22562] New: Add ItemHoldingLibrary to ReservesControlBranch
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '25

13 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22562 Bug ID: 22562 Summary: Add ItemHoldingLibrary to ReservesControlBranch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 35716] New: Duplicated assets in both koha-tmpl/intra-tmpl and koha-tmpl/opac-tmpl
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '25

12 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 Bug ID: 35716 Summary: Duplicated assets in both koha-tmpl/intra-tmpl and koha-tmpl/opac-tmpl Change sponsored?: --- Product: Koha Version: master 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: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart+koha(a)gmail.com, julian.maurice(a)biblibre.com, m.de.rooy(a)rijksmuseum.nl, martin.renvoize(a)ptfs-europe.com, tomascohen(a)gmail.com There are some JS assets duplicated in koha-tmpl/intra-tmpl and koha-tmpl/opac-tmpl. 100% match: ./koha-tmpl/opac-tmpl/bootstrap/js/i18n.js ./koha-tmpl/intranet-tmpl/js/i18n.js 100% match: ./koha-tmpl/opac-tmpl/bootstrap/js/Gettext.js ./koha-tmpl/intranet-tmpl/js/Gettext.js ~95% match: ./koha-tmpl/opac-tmpl/bootstrap/js/coce.js ./koha-tmpl/intranet-tmpl/js/coce.js ~95% match: ./koha-tmpl/opac-tmpl/bootstrap/js/cookieconsent.js ./koha-tmpl/intranet-tmpl/prog/js/cookieconsent.js ~80% match: ./koha-tmpl/opac-tmpl/bootstrap/js/ill-availability.js ./koha-tmpl/intranet-tmpl/prog/js/ill-availability.js ~50% match: ./koha-tmpl/opac-tmpl/bootstrap/js/basket.js ./koha-tmpl/intranet-tmpl/prog/js/basket.js Some of the differences in the above pairs may have been due to requirements specific to only staff or to only OPAC, or it may also have been the case that they have fallen out of sync over the years with some enhancements being added to one of the pair and not the other. I don't know what the best solution for this would be (if one is needed) but developing bug 35604 I need to have the same JS file on both intra and OPAC and feels bad to have to copy the same file to 2 different places. I'm only looking for JS files but I know this is also the case for images, maybe some CSS and other assets. Could we consider having a koha-tmpl/shared-tmpl directory, or have some of these overlapping assets only exist once and have them be duplicated for each interface during build, or yet another better option? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 58

[Bug 34864] New: Allow for Web Pages to be duplicated
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '25

10 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34864 Bug ID: 34864 Summary: Allow for Web Pages to be duplicated Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently, when creating web pages, you can create a page for one branch specifically but can't pick visibility to multi-libraries. Thus creating the need to create the same page multiple times if needed. It would be nice to allow for libraries to duplicate an existing page when needing to create a web page for multiple branches. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 40040] New: RTL CSS files not loaded in templates; legacy right-to-left.css causing UI issues
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '25

10 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40040 Bug ID: 40040 Summary: RTL CSS files not loaded in templates; legacy right-to-left.css causing UI issues Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: karamqubsi(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 182880 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=182880&action=e… RTL: Dropdown menus to have background colors that make text unreadable Hello everyone, Currently, the staff interface loads both regular CSS files for LTR and then adds `right-to-left.css` on top when in RTL (bidi) mode. This approach is inefficient and can lead to styling conflicts. The OPAC interface already correctly loads RTL-specific CSS files directly when in RTL mode. The right-to-left.css file is manually maintained and not generated by Gulp, unlike other RTL files that are automatically generated from their LTR counterparts. This results in inconsistent RTL styling. Currently, right-to-left.css is causing dropdown menus to have background colors that make text unreadable (see attachment). I preparing a patch to fix that. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 40692] New: Wrong color background in Perl modules page
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '25

10 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40692 Bug ID: 40692 Summary: Wrong color background in Perl modules page Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org Page About Koha, tab Perl Modules When a Perl module is missing or requires an update, Koha sets a background color, but when the module is OK (current) it doesn't reset the background color, so it will keep the background color from the previous checked module. This can make the page very confusing as Perl modules that are current will appear to be missing or need of an upgrade according to the background color but the title will give the correct information. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16