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

[Bug 41697] New: Update MARC21 default framework 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=41697 Bug ID: 41697 Summary: Update MARC21 default framework 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 Bibliographic 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/bibliographic/bdapndxg.html ■ New content designators: Subfields $i Relationship information (R) in 381 (Other Distinguishing Characteristics of Work or Expression) $z Title statement context note (NR) in 245 (Title Statement) $4 Relationship (R) in 381 (Other Distinguishing Characteristics of Work or Expression) ■ Changes in content designator names and definitions: Subfield $c Statement of responsibility, etc. redescribed in 245 (Title Statement) Appendix JData 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: New Subfields $6Linkage (NR) in 060 (National Library of Medicine Call Number) $6Linkage (NR) in 070 (National Agricultural Library Call Number) New Codes r - Remote sensing image in Maps 008/25 (Type of cartographic material) (006/08) t - 4K Ultra HD Blu-ray in Videorecording 007/04 (Videorecording format) Subfields $d Groove characteristic redescribed in 344 (Sound Characteristics) $g Conversion date renamed Conversion date/time and redescribed in 884 (Description Conversion Information) Code s - Blu-ray disc redescribed in Videorecording 007/04 (Videorecording format) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 41267] New: It should be possible to prevent some itemtypes from filling other biblio level holds
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Bug ID: 41267 Summary: It should be possible to prevent some itemtypes from filling other biblio level holds Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com See bug 40792 and related/dependent bugs. Currently Koha will fill any title level holds on a record when another item on the record is checked out. Some libraries want this behaviour, others don't want it for all item types. E.g. - A library has 'lucky day' item which cannot have holds placed. If a patron finds them in the library they can check them out. In some libraries they have similar circ rules and so the item should fill the hold In other libraries the lucky day items have a shorter circulation period, so the patron may still want the regular book with a longer circ We should add a circulation rule to determine if an item type should or should not fill other biblio level holds Filing as a bug since many libraries consider this a regression -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 51

[Bug 42524] New: Option to calculate priorities based on reservedate when moving hold to a new record
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42524 Bug ID: 42524 Summary: Option to calculate priorities based on reservedate when moving hold to a new record Initiative type: --- Sponsorship --- status: 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Depends on: 31698 Currently, when a hold is moved to a new record the hold is placed at the end of the priority list. It would be helpful to provide an option to work the moved hold into the priority list based on when the hold was created -- the moved hold would go after older holds, before newer holds. This does present a problem if the new target record has holds whose priority has been manually changed so that they are no longer in order of age. For the merging of bib records we addressed this same issue by fully rebuilding the priority list for the new merged bib, discarding any manual priority changes and putting all holds in order of age. We could take the same approach here. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31698 [Bug 31698] Add ability to move a hold to a new bibliographic record/item -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 36868] New: Add ability to automatically empty cart after placing holds ( staff interface and OPAC )
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36868 Bug ID: 36868 Summary: Add ability to automatically empty cart after placing holds ( staff interface and OPAC ) 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Some librarians would like to have the cart automatically clear itself after placing holds on items in the current cart. This would behave similar to how online retail/e-commerce sites work after one has purchased items. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 83

[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 39943] New: Add a separate PIN code field for accessing self service devices
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39943 Bug ID: 39943 Summary: Add a separate PIN code field for accessing self service devices Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Some libraries allow their patrons to authenticate to a self-checkout or an access control device with a short pin number. While this is user-friendly and compatible with numpad devices, from a security standpoint it is not acceptable to have such a weak pin code as the patron account password outside library premises in OPAC on the public internet. It would be useful to separate a weaker PIN code field from the borrowers.password field. This weaker PIN code would only be used for SIP2 and possibly SCO/SCI access in a more restricted environment. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 43064] New: memberentry.pl email fields need type of email not text
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43064 Bug ID: 43064 Summary: memberentry.pl email fields need type of email not text Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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, kyle(a)bywatersolutions.com Target Milestone: --- If you give the email fields a type of "email" (type="email"), you can use .checkValidity() to validate the fields with the browser. Then you could use .validationMessage to give instant feedback on what is being entered if .checkValidity() returns false. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 42558] New: reserves.reservedate should be datetime instead of date
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42558 Bug ID: 42558 Summary: reserves.reservedate should be datetime instead of date Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In front of work I intend to do on Bug 42524. In order to calculate priorities based on reservedate, the reservedate must include time. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 55

[Bug 43071] New: Test failures when Holds Allowed (daily) has a value
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43071 Bug ID: 43071 Summary: Test failures when Holds Allowed (daily) has a value Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- t/db_dependent/Holds.t, t/db_dependent/ILSDI_Services.t, and t/db_dependent/api/v1/holds.t all fail if the Holds Allowed (daily) circ rule has a value. They fail slightly differently for a non-zero value and for a zero. They pass if there is no value set for this rule. Non-zero: Test Summary Report ------------------- t/db_dependent/Holds.t (Wstat: 512 (exited 2) Tests: 74 Failed: 2) Failed tests: 64, 69 Non-zero exit status: 2 t/db_dependent/ILSDI_Services.t (Wstat: 256 (exited 1) Tests: 16 Failed: 1) Failed test: 6 Non-zero exit status: 1 t/db_dependent/api/v1/holds.t (Wstat: 2816 (exited 11) Tests: 12 Failed: 1) Failed test: 11 Non-zero exit status: 11 Parse errors: Bad plan. You planned 20 tests but ran 12. Zero: Test Summary Report ------------------- t/db_dependent/Holds.t (Wstat: 1024 (exited 4) Tests: 74 Failed: 4) Failed tests: 64-66, 69 Non-zero exit status: 4 t/db_dependent/ILSDI_Services.t (Wstat: 512 (exited 2) Tests: 8 Failed: 2) Failed tests: 6-7 Non-zero exit status: 2 Parse errors: Bad plan. You planned 16 tests but ran 8. t/db_dependent/api/v1/holds.t (Wstat: 2816 (exited 11) Tests: 12 Failed: 1) Failed test: 11 Non-zero exit status: 11 Parse errors: Bad plan. You planned 20 tests but ran 12 -- You are receiving this mail because: You are watching all bug changes.

1 0

[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