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

[Bug 25586] New: Something wrong with KOHA_HOME
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25586 Bug ID: 25586 Summary: Something wrong with KOHA_HOME Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: mirko(a)abunchofthings.net -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 41932] New: Allow optional zero-padding in items.cn_sort
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 Bug ID: 41932 Summary: Allow optional zero-padding in items.cn_sort Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified 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 We have callnumbers like 1 A 1, 10 A 10, 100 A 100 and 1000 A 100. Alphabetically sorting those does not work (100 A 100 < 2 A 2) This proposal includes adding a syspref to define callnumber formats that also specify the desired length when zero-padding cn_sort. This would be active when using C4::ClassSortRoutine::Generic. In the above case we would like to sort them with 0001 A 001, 0010 A 010, 0100 A 100 and 1000 A 100. So the first digit block has length 4, the second block 3. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 98

[Bug 43393] Batch patron modification only saves the changes for shown entries
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43393 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |minor CC| |dcook(a)prosentient.com.au Summary|Batch patron modification |Batch patron modification |only saves the changes for |only saves the changes for |showed entries |shown entries Status|NEW |CONFIRMED --- Comment #4 from David Cook <dcook(a)prosentient.com.au> --- This is an issue with many parts of Koha that use server-side/API driven DataTables, since they only fetch data on demand. I think these UIs would need to be re-designed to be able to work as users would expect them to work (ie with good UX). The workaround is to change the DataTable so that it says "Show All entries" if you need to modify entries that are found across different pages. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 34808] New: Batch Patron Modification Tool - Select all / clear all does not select/clear all
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34808 Bug ID: 34808 Summary: Batch Patron Modification Tool - Select all / clear all does not select/clear all 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: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1. Open the Batch Patron Modification Tool 2. Insert or open a file with 25+ card numbers or borrower numbers to modify then click on continue. 3. Notice that there are 2 or more pages of entries showing. If you click on clear all, it will only clear entries 1-20 but not anything on the second page (21-...). Similarly if you clear both pages and try to select all, it will only select the entries on the page you are viewing. It would useful if the select all/clear all worked on all entries. Especially for libraries that are modifying hundreds of patrons. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 43393] Batch patron modification only saves the changes for showed entries
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43393 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Laura.escamilla@bywatersolu | |tions.com --- Comment #3 from David Cook <dcook(a)prosentient.com.au> --- *** Bug 34808 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 41913] New: Batch patron modification only affects on patrons that are visible in the tool
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41913 Bug ID: 41913 Summary: Batch patron modification only affects on patrons that are visible in the tool Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: anni.maki-mantila(a)turku.fi QA Contact: testopia(a)bugs.koha-community.org If patrons are divided to several pages in batch patron modification -tool, Koha makes the modification only to those patrons that are visible on the first page. The modification should affect on every patron that has been brought to the modification tool, regardless of how many patrons are shown per page. In version 24.05 this has worked properly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 43393] Batch patron modification only saves the changes for showed entries
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43393 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |anni.maki-mantila(a)turku.fi --- Comment #2 from David Cook <dcook(a)prosentient.com.au> --- *** Bug 41913 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 41407] New: OPAC hold history sorts newest to oldest but hides newest to limit to 50
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41407 Bug ID: 41407 Summary: OPAC hold history sorts newest to oldest but hides newest to limit to 50 Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Sort of hold history on the opac is unintuitive. It seems like if it's sorting newest to oldest, it should show the 50 newest holds, not active holds then oldest->newest holds until 50. To recreate on main: 1. Allow to override holds in system preferences 2. Allow borrowers to see HoldHistory in the OPAC 3. place at least 51 holds for a single patron. 4. Backdate some of the hold dates to past days, set one of them to be newer than the rest. 5. log in as that patron on the OPAC 6. Go to the holds history 7. observe the 50 holds and see that your newest one doesn't show 8. click the link to view all and see your newst one does show. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 39813] New: z3950_responder.pl needs support for authentication
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39813 Bug ID: 39813 Summary: z3950_responder.pl needs support for authentication Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl At the moment, z3950_responder.pl only provides anonymous access via Z39.50. That means if you want to restrict your Z39.50 endpoint using a username and password, you're forced to use Zebra. If z3950_responder.pl had support for authentication, then it would be one more nail in the coffin for Zebra, as you wouldn't need Zebra for that use case anymore. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 38666] New: New feature: closed stack requests
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38666 Bug ID: 38666 Summary: New feature: closed stack requests Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Circulation Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com A closed stack request is a special kind of hold that can only be placed on a closed stack item. A closed stack item is an item that is not available publicly in the library but can be made available on demand. When a request is made, a librarian will print a slip then will go retrieve the document and place the slip in place of the document. -- You are receiving this mail because: You are watching all bug changes.

1 111