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

[Bug 18410] New: Koha should use cool URIs
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18410 Bug ID: 18410 Summary: Koha should use cool URIs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: pablo.bianchi(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Right now Koha use a very volatile URI scheme. If we seek having not ephemeral URIs they should be completely different. Take a look to this article from 1998 of a guy called Tim Berners-Lee: "Cool URIs don't change" https://www.w3.org/Provider/Style/URI A normal Koha URI looks like this: https://catalog.bywatersolutions.com/cgi-bin/koha/opac-detail.pl?biblionumb… This URI is doomed to die in the short term, is not designed thinking in long-term. We have a lot of information about the tools and technical things used to put it there, like "cgi-bin", "koha" and "pl". Is not even consistent about using always en_US (american English): "/cgi-bin/koha/cataloguing/addbooks.pl" (cataloguing != cataloging). As the article say we shouldn't forget about domain name. We could encourage the use of more permanent words like "catalog" for the host part of the FQDN. PS: This may be related to the robust RESTful URI. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 39714] New: Optionally do not count waiting or suspended holds toward hold limits
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39714 Bug ID: 39714 Summary: Optionally do not count waiting or suspended holds toward hold limits Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When enforcing how many holds a patron is allowed, some libraries would prefer not to count waiting or suspended holds. We could add a system preference that allows one to configure which hold statuses to count toward limits. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 25667] New: Add field for items.notforloan_on to record when a notforloan status is applied
by bugzilla-daemon＠bugs.koha-community.org 15 Jul '26

15 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25667 Bug ID: 25667 Summary: Add field for items.notforloan_on to record when a notforloan status is applied Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We record lost_on and damaged_on. Can we record notforloan_on, too? It'd be helpful for various reports. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 35693] New: Granular Permissions to Everything
by bugzilla-daemon＠bugs.koha-community.org 15 Jul '26

15 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35693 Bug ID: 35693 Summary: Granular Permissions to Everything 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I don't know exactly how to file this. Koha is growing all the time and new features are always being added, but they are often being added with very little permission granularity. Often the permissions are too broad. For example, the newer pages under additional-contents.pl is under the entire umbrella of one permission for the user, and gives them access to ALL pages, ALL news, and ALL HTML customizations. I am hoping that Koha will start thinking more about roles in the library, and allowing us to give specific people access to specific pages, customizations, etc. This goes even further with who can override things. We don't have a lot of control over who can do what specific things. Maybe there is a bug on this topic already? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 34626] New: Add waiting since date to holdswaiting patron message
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34626 Bug ID: 34626 Summary: Add waiting since date to holdswaiting patron message 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 On moremember.tt and ciculation.tt there will be a message if the patron has any waiting holds. This message displays the date the hold was placed on (reserves.reservedate) and the date it will wait until ( reservedate.expirationdate ). Some libraries would like to add the 'Waiting since' date. ( reservedate.waitingdate ) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 41702] New: Update MARC21 authority frameworks to Update 41 (December 2025)
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41702 Bug ID: 41702 Summary: Update MARC21 authority frameworks to Update 41 (December 2025) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org https://www.loc.gov/marc/authority/adapndxf.html UPDATE 41 CHANGES ■ New content designators: Subfields $i Relationship information (R) in 368 (Other Attributes of Person or Corporate Body) $i Relationship information (R) in 376 (Family Information) $i Relationship information (R) in 381 (Other Distinguishing Characteristics of Work or Expression) $4 Relationship (R) in 368 (Other Attributes of Person or Corporate Body) $4 Relationship (R) in 376 (Family Information) $4 Relationship (R) in 381 (Other Distinguishing Characteristics of Work or Expression) ■ Changes in content designator names and definitions: Subfield $2 Source redescribed in 368 (Other Attributes of Person or Corporate Body) Appendix HData Provenance Subfields: Data Provenance Code List moved to https://www.loc.gov/standards/valuelist/dataprov.html. New codes bcp47 and dpets added. ■ Fast-track changes: Subfields $g Conversion date renamed Conversion date/time and redescribed in 884 (Description Conversion Information) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 41479] New: Remove Baker & Taylor integration
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41479 Bug ID: 41479 Summary: Remove Baker & Taylor integration Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Baker & Taylor will soon be no more: https://www.publishersweekly.com/pw/by-topic/industry-news/publisher-news/a… -- You are receiving this mail because: You are watching all bug changes.

1 37

[Bug 32756] New: Additional fields: Allow additional fields to be defined as links
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32756 Bug ID: 32756 Summary: Additional fields: Allow additional fields to be defined as links 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, michaela.sieber(a)kit.edu Blocks: 32751 Sometimes you will want to link from Koha to external pages. For example you might want to link from your subscription to the vendor's page for the serial or from your basket to your order on the vendor's website. For this it would be nice if you could configure additional fields to be links. It would be especially nice if it allowed you to specify a link with a place holder, that is then entered into the field, creating the link. For example your configuration could be: [x] Is a link Link structure: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id={data} Link text: Bug {data} Then in the form, you'll just enter the number: 32751 And on all pages that display the link, this would create a link to: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32751 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32751 [Bug 32751] [Omnibus] Extend, improve and standardize additional fields -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 32327] New: When replacing bib record via z39.50, only 1 ISBN should be searched and it should be normalized
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32327 Bug ID: 32327 Summary: When replacing bib record via z39.50, only 1 ISBN should be searched and it should be normalized Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The replace via z39.50 function pre-populates the z39.50 search form with values from the existing bib. Koha just pastes in the contents of biblioitems.isbn, which means it very often pre-populates that field with a value that will never find anything. If the existing record has more than 1 ISBN, the prepopulated form will list them all, pipe-separated. This search will always return no results, even when either ISBN returns results successfully on its own. If the existing record contains a parenthetical note about binding, that search will generally fail as well. We should only put the first ISBN from the record into the search form and we should strip out any binding note or other fluff. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 38621] New: [% today %] variable unavailable in report templates
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38621 Bug ID: 38621 Summary: [% today %] variable unavailable in report templates Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I tried adding a date to a report template, but it doesn't seem to work. I was told on MM that this is a bug. To recreate: 1. Create a report notice template with [% today %] 1.1. Go to Tools > Notices and slips 1.2. Click New notice > Reports 1.3. Enter a code and a name 1.4. Click Email 1.5. Enter a subject 1.6. In the message body, add some info with [% today %], here is what I used [% USE KohaDates %] [% today | $KohaDates %] [% FOREACH d IN data %] [% d.title %] [% END %] 1.7. Click Save 2. Create a report that works with this template 2.1. Go to Reports > Create from SQL 2.2. Enter a report name 2.3. In the SQL field, enter a report that would work with the template, this is what I used SELECT * from biblio limit 1 2.4. Click Save report 3. Click Run with template > Template name --> The date doesn't appear I also tried with a the simple [% today %] without the USE and without the KohaDates filter, but it doesn't show the date either. If I don't put the USE but use the filter, the template simply doesn't work (when you click Run with template > Template name, the report is displayed as normal in table form). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27