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

[Bug 41133] New: Suggestions table sharing localStorage for all tabs can prevent records from loading
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41133 Bug ID: 41133 Summary: Suggestions table sharing localStorage for all tabs can prevent records from loading Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: blawlor(a)clamsnet.org QA Contact: testopia(a)bugs.koha-community.org On suggestion.pl the local storage DataTables_acqui_suggestions_suggestions which saves the state for pagination is shared for all tabs, which can cause tabs to load with a bad state and fail to load records. To recreate: 1. Use ktd --dbshell to add a bunch of random suggestions with different statuses: INSERT INTO suggestions (suggestedby, suggesteddate, title, status) SELECT borrowernumber, '2025-10-29', firstname, ELT(0.5 + RAND() *6, 'ASKED', 'CHECKED', 'ACCEPTED', 'REJECTED', 'ORDERED', 'AVAILABLE' ) from borrowers; 2. If you are lucky you will have one tab with more than 20 records and one with less than 20, if not use the ui to adjust the statuses so that you do 3. Click on a tab with more than 20 records 4. Click Next > to go to the second page 5. Notice in local storage now DataTables_acqui_suggestions_suggestions.start is now 20 6. Click on a tab with fewer than 20 records 7. Notice the table says something illogical like: Showing 21 to 11 of 11 entries 8. And no records load :( 9. Click <<First to fix the pagination issue 10. Notice DataTables_acqui_suggestions_suggestions.start is now 0 again 11. The table loads with records :) Showing 1 to 11 of 11 entries -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 41049] New: Add additional deleting capabilities to the cataloging macros
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41049 Bug ID: 41049 Summary: Add additional deleting capabilities to the cataloging macros Change sponsored?: --- 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: maxeinergl(a)gcc.edu QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be helpful to have syntax added to the Advanced Editor's cataloging macros for the following: 1) ability to delete fields based on indicator 2) ability to delete subfields on all instances of a field, not just the first instance of the subfield / first instance of the field. A use case scenario would be importing records from Z39.50 sources and using a macro to strip fields/subfields that are always unwanted. Deleting fields based on indicator would allow one to strip subjects from unwanted thesauri, for example 650 _1... for a juvenile SH or 650 _2 for MESH. Deleting subfields on all instances would allow one to strip coded and linking subfields from authorized heading fields. Sometimes the same subfield repeats in the same instance of the field (for example, multiple $4's in a 100 field), and sometimes a field number has multiple instances (for example, multiple 650 fields, all with $0 linking subfields). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 32196] New: One should be able to remove a borrower relationship whenever one exists
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32196 Bug ID: 32196 Summary: One should be able to remove a borrower relationship whenever one exists Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 12446 Per bug 32195, there is still at least one way for a patron to end up with a guarantor in a category that does not allow guarantors. When that happens, the patron edit screen does not show one the relationship and therefore the relationship cannot be removed. One should *always* be able to remove an existing relationship. To recreate: 1: have a patron category where CanBeGuarantee is set to Yes. 2: Create a patron in that category, give them a guarantor 3: edit the patron category to set CanBeGuarantee to No 4: confirm your patron still has a guarantor that shows on the details page, but the guarantor no longer shows on the edit screen 5: this means the guarantor cannot be removed :( Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12446 [Bug 12446] Enable an adult to have a guarantor -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 31681] New: Daily digest notice for ALL notices
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31681 Bug ID: 31681 Summary: Daily digest notice for ALL notices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org What if a patron had the option to have a SINGLE notice per day, that was a digest of all notices to them? So, if they have this option checked, they would get a notice at the end of the day, or beginning, that would contain any hold, overdue, predue, etc notices. So, if this is checked, instead of queuing up for the regular cron, maybe the notice is sent in a new cron that is once a day. If done, it might also be beneficial to note on the parton's notifications how the notification was queued (right away/daily). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 20747] New: Allow LocalHoldsPriority to fill by hierarchical groups system rather than individual library
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20747 Bug ID: 20747 Summary: Allow LocalHoldsPriority to fill by hierarchical groups system rather than individual library 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: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com It would be great if the LocalHoldsPriority could be used within a district in a consortium. >>Christopher expressed concern, adding on “grouping” – some libraries may not >>want to be effected. Typically this is all or nothing or on or off. Example, >>the circulation of Mobile Hotspots; hotspots are popular outside of CDA but CDA >>patrons get priority, Rathdrum is pushed down. Consider an “Item type” or “Item >>level” opt out which would be similar to how suppression works. If the >>modification increased features and flexibility, there may be more interest from >>the larger group in supporting the enhancement. Group structure for settings, a >>hierarchy based system, and refinement is needed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 87

[Bug 38289] New: ILL module should create biblios for DVD and Thesis documents
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38289 Bug ID: 38289 Summary: ILL module should create biblios for DVD and Thesis documents Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: sonia.bouis(a)univ-lyon3.fr QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com At the moment, ILL Module create biblios records only if the document is a book type. As DVD and Thesis are physical documents too, ILL module should create a biblio for these types of document too. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 36350] New: Add subclass of Koha::Objects that provides caching for find
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36350 Bug ID: 36350 Summary: Add subclass of Koha::Objects that provides caching for find Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org At our library we have traced some performance issues to repeated find calls for a number of object types. To address this patch introduces a subclass for Koha::Object that if extended instead of the former provides a cached version of find. This patch enables caching for ItemTypes and Libraries which I believe are called repeatedly for the same objects much than the others. Other possible candidates are Patrons and Items but will have to do some more digging to find out if it makes much a difference. It's easy to enable/disable by just switching out the base class for the Koha::Object and Koha::Objects derived classes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 77

[Bug 38647] New: Can't filter holdings table by shelving location
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38647 Bug ID: 38647 Summary: Can't filter holdings table by shelving location Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In 24.05, libraries can no longer filter the holdings table in the staff interface by shelving location since the Home library column is now a drop-down instead of allowing free text entry. As of 23.11, the filtering was free text instead of a drop-down, which meant that libraries could type a library name *or* a shelving location to filter. Additionally, the holdings table search bar doesn't appear to 'read' shelving locations, so libraries can't use that to pinpoint items with a specific shelving location either. This will likely be moot with Bug 15461 - Add staff equivalent for OpacLocationOnDetail, but in the meantime, it isn't user-friendly for libraries who need that column to filter bibs with many holdings. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 34164] New: OAuth2/OIDC should redirect to page that initiated login
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34164 Bug ID: 34164 Summary: OAuth2/OIDC should redirect to page that initiated login Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org At the moment, a successful OAuth2/OIDC login is sent to opac-user.pl/opac-main.pl or mainpage.pl instead of the page that initiated the login process. With Shibboleth, we manage this using the "target" URL, so that the Shibboleth login is processed by whatever page initiated it, but that doesn't work with OAuth2/OIDC and the "redirect_uri" since we're using an API endpoint. However, all we need to do is save the current path in the user's session, and then recall it after the successful login. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 44

[Bug 29948] New: Display author information for researches
by bugzilla-daemon＠bugs.koha-community.org 24 Aug '26

24 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29948 Bug ID: 29948 Summary: Display author information for researches Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: OPAC Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 29897 Display author's information from 371, 372, 373 (email, activity, etc.) in the same area than identifiers (from bug 29897). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29897 [Bug 29897] Display author identifiers for researchers -- You are receiving this mail because: You are watching all bug changes.

1 68