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

[Bug 36724] New: Add cartographic mathematical data to Elasticsearch index mappings
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36724 Bug ID: 36724 Summary: Add cartographic mathematical data to Elasticsearch index mappings Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz Search whole 255 field https://www.loc.gov/marc/bibliographic/bd255.html Test with values like * Scale 1:22,000,000 * Conic proj. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 33374] New: Holds captured at different branch when pickup branch has a copy on shelf can create long wait times for patrons
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33374 Bug ID: 33374 Summary: Holds captured at different branch when pickup branch has a copy on shelf can create long wait times for patrons Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: 1. Have a multibranch system where holds can transfer between 2 or more libraries 2. Have a bib with 2 or more items at different branches. 3. At Branch A checkout Branch A's copy of the item to a patron 4. At Branch B place a record level hold for a Branch B patron (where branch b has a copy of the item available on the shelf) 5. Return Branch A's book at Branch A. It fills the hold for Branch B patron In some cases this makes the patron wait much longer for a hold. It would be great if there was a way to set holds not to fill from other libraries if there was a copy available at the pickup location. Some consortiums have branches that only get deliveries once or twice a week. If they happen to check in an item that could be filled at the pickup branch before the pickup branch scans the hold there, it could take much longer for the patron to get the item. Lisette -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 30682] New: Indicate in addbiblio.pl when an edit will not be saved due to Overlay Rules
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30682 Bug ID: 30682 Summary: Indicate in addbiblio.pl when an edit will not be saved due to Overlay Rules 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 14957 The new MARC overlay rules can prevent edits to certain MARC fields. We don't give any indication when that's happening. To recreate: - set a rule on marc-overlay-rules.pl for module=source, filter=Staff client MARC editor, tag=020, preset=protect - find a record with an 020 - edit the record, delete the 020, save. confirm the interface allows all of this - confirm the 020 is still there, but no indication of why Something here should inform the user of what's going on. Highlighting of the tag within the edit interface? A popup on saving? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957 [Bug 14957] Write protecting MARC fields based on source of import -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 26573] New: Limit patron attribute types to more than one patron category
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26573 Bug ID: 26573 Summary: Limit patron attribute types to more than one patron category 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 Currently, Koha doesn't allow to limit a patron attribute type to more than one patron category. Let's say I have a patron attribute type STUDENTID, and I want to limit this attribute to the categories "undergrad students" and "grad students". I have to create two different patron attribute types. To replicate: 1) Go to Administration > Patron attribute types 2) Create a new patron attribute 3) Note that the "Category" field is a dropdown and you can't choose more than one patron category to assign this attribute type to. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 94

[Bug 37745] New: "Rows per page" not working
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37745 Bug ID: 37745 Summary: "Rows per page" not working Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 41191] New: Multiselect in borrower attributes
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41191 Bug ID: 41191 Summary: Multiselect in borrower attributes 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 I know that it is possible to make a patron attribute repeatable, but I am wondering if it would be possible or beneficial if a patron attribute, if assigned to an authorized value, could it be made so that you could multiselect from that list, like we do with the library limitations, and have those values stored in the field with the separator? This would give us the option of using repeatable fields or having one with multiple choices, and taking up less real estate on the screen if many selections are made/needed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 42865] New: as_marc_field losing more_subfields_xml data after new MARC mapping
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42865 Bug ID: 42865 Summary: as_marc_field losing more_subfields_xml data after new MARC mapping Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: jake.deery(a)openfifth.co.uk, robin(a)catalyst.net.nz Target Milestone: --- Hello, When a MARC subfield was previously unmapped (its value stored in more_subfields_xml) and a new mapping was added linking it to a Koha items column, running batchRebuildItemsTables.pl would permanently lose the value. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 17593] New: Extend circulation rules to include shelving location
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17593 Bug ID: 17593 Summary: Extend circulation rules to include shelving location Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: stefan.berndtsson(a)ub.gu.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We are in the process of moving over to Koha, and are still trying to manage all the details around this. Circulation rules are a big thing we have to tackle here. At the moment, we have multiple libraries, and within each library we have both open and closed stacks as well as multiple other segmentations, all specified as shelving locations (authorized value LOC). These locations are not always governed by the same set of rules, so it would be very helpful if the system could support LOC as a circulation rule condition alongside library, patron category and item type. >From doing a fairly brief look at the code, it seems GetIssuingRule and GetLoanLength in C4/Circulation.pm are the main points where the ruleset is retreived. There will of course be all the places calling these two functions, as well as database management parts to consider. If we were to develop some sort of extension to these rules, what would be an appropriate approach? It should certainly be an option to turn on to be used, but should we consider LOC as a starting point, or should LOC just be one many possible choices in the configuration? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 40881] New: Table layout overflow on course interface – table extends beyond container
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40881 Bug ID: 40881 Summary: Table layout overflow on course interface – table extends beyond container Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org The Course interface (Course Reserves) page shows a layout issue: the results table overflows horizontally and extends beyond its container. Steps to reproduce 1. Log in to the staff interface. 2. Go to Course reserves. 3. Click New course, fill in the required fields, and click Save. 4. Click Add reserves, add items or biblionumbers, click Submit, then click Save to add reserve. 5. Click Cancel to see the Course details Table ---> table extends beyond container -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 42982] New: impossible to scroll down the list of cataloging framework when cataloging
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42982 Bug ID: 42982 Summary: impossible to scroll down the list of cataloging framework when cataloging Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Hi, when we have more than 27 grids and When cataloging a document and wanting to select a specific cataloging framework, it's not possible to see all the Library's cataloging grids. Normally, we should be able to scroll down to see the available options. However, this isn't possible. We must zoom in to access the cataloging grids at the bottom of the list. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8