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

[Bug 32459] New: Add option to expire patrons who were updated in the update_patrons.pl cron job
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32459 Bug ID: 32459 Summary: Add option to expire patrons who were updated in the update_patrons.pl cron job Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com A common use of the update_patrons.pl is to update a child card to an adult account. It would be really helpful to be able to expire the account when the patron category is changed. The reason behind this specific situation is when patrons become "adults" libraries need to get a new application form signed, so the individual is now responsible for the account. Perhaps there can be a way to set the expiration date to the current date when those accounts are updated? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 31406] New: Set focus for cursor to setSpec input when adding a new item search field
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31406 Bug ID: 31406 Summary: Set focus for cursor to setSpec input when adding a new item search field Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When adding a new item search field from administration, the focus/cursor should be in the first field of the entry form: Name -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 24535] New: Add the ability to have longer barcodes than 20 digits
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24535 Bug ID: 24535 Summary: Add the ability to have longer barcodes than 20 digits Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: nick(a)bywatersolutions.com Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently, in Koha, an item's barcode can only be up to 20 digits, it would be nice to increase this value to possibly a higher number such as 32. Koha recently increased the patron's barcode length to 32 and it was helpful to libraries. -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 34563] New: Move IntranetCirculationHomeHTML to HTML customizations
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34563 Bug ID: 34563 Summary: Move IntranetCirculationHomeHTML to HTML customizations 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Bug 6419 adds some HTML customizations to the staff interface. IntranetCirculationHomeHTML is still a system preference. It would be nice to move it to HTML customizations with the others. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 37

[Bug 32767] New: Trimming of attribute types by wish (if enabled)
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32767 Bug ID: 32767 Summary: Trimming of attribute types by wish (if enabled) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Patrons Assignee: stalkernoid(a)gmail.com Reporter: stalkernoid(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com, nugged(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 46

[Bug 27364] New: Making previous patron cardnumbers searchable
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27364 Bug ID: 27364 Summary: Making previous patron cardnumbers searchable Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: fiona.borthwick(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 18626 introduced the logging of changes to patron cardnumbers which is great, but this still does not link together previous cardnumbers. Imagine this scenario: A library patron loses their library card. They are issued with a replacement. Old and new cardnumbers are recorded in the Modification log. The old card is found (doesn't matter who finds it) and brought to the library. A member of library staff scan the barcode - get no results. This means they are none the wiser as to who this card belonged to. Would it not be a good idea to allow previous cardnumbers to be searchable? Some libraries may record this information somewhere in the patron record, but a search by cardnumber would be extremely helpful. It would be useful if the cardnumber moved into a linked field automatically when a new cardnumber was entered. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 35052] New: OpacHiddenItemsHidesRecord system preference should be considered on index time instead
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35052 Bug ID: 35052 Summary: OpacHiddenItemsHidesRecord system preference should be considered on index time instead Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: alexander.blanchard(a)ptfs-europe.com, dcook(a)prosentient.com.au, jacob.omara(a)ptfs-europe.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com Currently, results are being skipped after the search has been processed in C4/Search.pm. This may cause several unintended scenarios: 1) The first page has all the results skipped, even thought there are more results in 2nd page and so on, this will will result in a "No search results" page 2) The total search results number still shows 80 (for example), even if it has skipped 70 and is only showing 10. To reproduce we need to use both OpacHiddenItems and OpacHiddenItemsHidesRecord Use OpacHiddenItems and put some rules that hide some items Use OpacHiddenItemsHidesRecord = 'hide' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 37

[Bug 24910] New: Make it possible to choose see also-authorities in authority finder
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24910 Bug ID: 24910 Summary: Make it possible to choose see also-authorities in authority finder 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When searching for authorities, sometimes you may see the result you want to select in a see also, but it is not possible to *choose* that one. You have to do another search to get it into the results list of auth finder. Wouldnt it be nice if we could somehow add a link to choose them too? The current link allows you to open them, but this seems less useful at least in our case. Would a preference be useful to switch between choosing or opening ? Or should we add a small link? How could we address that best in terms of styling etc? Your feedback is appreciated ! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 37985] New: Extend geo-search to support areas, not just points (MARC 034 subfields defg)
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37985 Bug ID: 37985 Summary: Extend geo-search to support areas, not just points (MARC 034 subfields defg) Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: tadeusz(a)sosnierz.com QA Contact: testopia(a)bugs.koha-community.org Bug 31652 ("Add geo-search") implements indexing geographic coordinates (034s,t) in Elasticsearch to enable searching for records referring to specific coordinates. Some records (or authorities) will refer to whole areas, which MARC encodes as north/south/east/westmost points. Since elasticsearch supports indexing shapes, not just points, it would be a nice improvement to be able to index this as well. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 36633] New: Support anti-the at REST API level
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '26

20 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36633 Bug ID: 36633 Summary: Support anti-the at REST API level Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com CC: tomascohen(a)gmail.com Coming from bug 35560. If we migrate UI tables to DT using the REST API we need support the anti-the sorting type. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11