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

[Bug 30759] New: Add hint about the data that is sent via the Google Books API to OPACSuggestionAutoFill
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '26

30 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30759 Bug ID: 30759 Summary: Add hint about the data that is sent via the Google Books API to OPACSuggestionAutoFill Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 14242 On bug 14242 Victor suggested to add a hint to the OPACSuggestionAutoFill system preference that explains about possible implications to data privacy and lists which data is sent via the Google Books API: (In reply to Victor Grousset/tuxayo from comment #118) > And meanwhile, should a small warning in the syspref description be added? > So the library can update their documents about their personal data > processing. > > Something like «Personal data processing: Google will receive the following > data: IP address, OS name, web browser version, preferred languages, and the > ISBNs of the books suggested.» Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14242 [Bug 14242] Use ISBN-field to fill out purchase suggestions using Google Books API -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 17180] New: Add a current date macro to the advanced cataloging editor
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '26

30 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17180 Bug ID: 17180 Summary: Add a current date macro to the advanced cataloging editor Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 42945] New: When a waiting hold is filled by another item it should have a status that can be seen in the interface
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '26

30 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42945 Bug ID: 42945 Summary: When a waiting hold is filled by another item it should have a status that can be seen in the interface 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: 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 Target Milestone: --- When a hold is filled by a different item, it can leave another item waiting on the hold shelf, with no way for staff to check. We should add a status to these holds/items that cleared on checkin, and offer a way for staff to view these - on the holds over tab, or somewhere obvious -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 42483] New: HoldsQueuePrioritizeBranch description should say hold pickup library instead of patron's home libary
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '26

30 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42483 Bug ID: 42483 Summary: HoldsQueuePrioritizeBranch description should say hold pickup library instead of patron's home libary 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: 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 The description for HoldsQueuePrioritizeBranch reads "The holds queue should prioritize filling a hold by matching the patron's home library with an item having a matching (home library / holding library)." However, it actually attempts to match the hold pickup branch to either the item homebranch or the item holdingbranch. It should be reworded. To confirm the current behavior: - have transport cost matrix and LocalHoldsPriority off - Have a patron with home of Branch A - Have a bib with two available items -- Item 1 is homebranch and holdingbranch A -- Item 2 is homebranch and holdingbranch B - place a hold for your patron patron to be picked up at Branch B - build holds queue - see it targets the item at Branch B (hold pickup) rather than the item at branch A (patron home) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 42939] New: Using ILL requests backend filter breaks status filter
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '26

30 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42939 Bug ID: 42939 Summary: Using ILL requests backend filter breaks status filter Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: aude.charillon(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- This issue was first spotted in 25.11.04 and confirmed on Main. To replicate: 1. Enable the ILLModule system preference. 2. Navigate to /cgi-bin/koha/ill/ill-requests.pl (In main: Interlibrary loans > Visit ILL requests (previously ILL module).) 3. Create at least two ILL requests, with different destination libraries. 4. Update the status of one of the requests: 4a. Click Manage request then the Confirm request button. 4b. On the next screen, click the Confirm request button again. This marks the request as Requested and returns you to the Manage request screen. 5. Click the List requests above the request details. This returns you to the page in step 2. 6. In the Filters, select Status = New request and click Search. A request correctly displays. 8. Use the Clear button. The Filters are cleared of your selection and all requests correctly display. 9. In the Filters, select Status = New request + Destination library = the library of your new request and click Search. The request correctly displays. 11. Use the Clear button. The Filters are cleared of your selection and all requests correctly display. 10. In the Filters, select Backend = Standard and try to select a Status: the Status dropdown doesn't open, with no indication of why. 12. Use the Clear button. The backend filter is cleared but a second Status selector box appears. 13. Note: only the first Status selector is clickable. It actually works for searching. The second one doesn't disappear when using the Clear button; the only way to get rid of it is to refresh the page. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 30200] New: Add customizable tabs to interlibrary loan requests list
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '26

30 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30200 Bug ID: 30200 Summary: Add customizable tabs to interlibrary loan requests list 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: lari.taskula(a)hypernova.fi In staff client, all interlibrary loan requests are loaded into a table regardless of their status. Ability to sort them by status under multiple tabs would make librarians life a lot easier. This Bug adds such feature. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 80

[Bug 27113] New: ElasticSearch: Autocomplete in input search
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '26

30 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27113 Bug ID: 27113 Summary: ElasticSearch: Autocomplete in input search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: ivan.dziuba(a)inlibro.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 298

[Bug 15428] Different timeout preference for OPAC and staff interface
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '26

30 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15428 Anke Bruns <anke.bruns(a)gwdg.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |anke.bruns(a)gwdg.de --- Comment #27 from Anke Bruns <anke.bruns(a)gwdg.de> --- We would really appreciate this to be accomplished soon, is this possible? As it is, the system preference, I'm sorry to say, is useless to our librarians. Thanks a lot! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42944] New: Option to stop auto-renewals for indivdual checkouts
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '26

30 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42944 Bug ID: 42944 Summary: Option to stop auto-renewals for indivdual checkouts Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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, kyle(a)bywatersolutions.com Target Milestone: --- At the moment items are auto-renewed if the checkbox for auto-renewals is checked on checkout or if the circulation rules are set up to auto-renew for the item. There is an option to opt-out of auto-renewal for individual users in the patron record. It would be nice if auto-renewals could also be removed/stopped on checkout level. This could be a checkbox that is set on checkout in the patron account's checkout options or a way to remove the auto-renewal flag from the checkout list, maybe per batch operation (check multiple and have a button or similar at the bottom of the list). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 25159] New: Action logs should be stored in JSON ( and as a diff of the change )
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '26

30 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25159 Bug ID: 25159 Summary: Action logs should be stored in JSON ( and as a diff of the change ) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Action logs would be much more readable if we changed the format from a raw Data::Dumper::Dumper string to JSON which we could format nicely in the interface. In addition, we could store changes to database rows ( and other data structures ) as a diff stored in JSON. I think the format from Struct::Diff::diff is nice. Given: my $x = { surname => 'Hall', firstname => 'Kyle', cardnumber => '12345', suffix => "Jr.", }; my $y = { surname => 'Hall', firstname => 'Kyle', cardnumber => '9876543', nickname => "K-dog" }; The diff looks like: { "D": { "cardnumber": { "N": "9876543" }, "nickname": { "A": "K-dog" }, "suffix": { "R": "Jr." } } } Where the D key is the difference, and indicates cardnumber has changed with an N, nickname has been added with an A, and suffix has been removed with an R. With this data we can easily construct a nice diff view ( perhaps green for added, red for removed, and yellow for changes showing the old and new value ). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 94