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

[Bug 41835] New: Add item forms Tag editor buttons on serial edition page are misaligned
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41835 Bug ID: 41835 Summary: Add item forms Tag editor buttons on serial edition page are misaligned Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org Created attachment 193003 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=193003&action=e… Wonky tag editor buttons To reproduce: 1. Make sure MARC framework for serials uses plugins in some 952 fields (e.g. dateaccessioned.pl plugin in field 952$d). 2. Find an active serial subscription and receive items for it. 3. Open Add item form. -> Note that Tag editor buttons aren't displayed inline with input fields. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 39299] New: cn_browser on 952$o fails to open from item editor
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39299 Bug ID: 39299 Summary: cn_browser on 952$o fails to open from item editor 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Since bug 30975 if you set the cn_browser plugin for 952$o it fails to open in the item editor. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 35143] New: Add hooks for status changes to ILL requests to send_staff_notice
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35143 Bug ID: 35143 Summary: Add hooks for status changes to ILL requests to send_staff_notice 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: philip.orr(a)lmscloud.de CC: pedro.amorim(a)ptfs-europe.com If the library is using ILL, currently Email notifications can only be (automatically) sent to ILL staff when a patron makes a request to modify or cancel an existing request. The notice templates for those two cases are ILL_REQUEST_CANCEL and ILL_REQUEST_MODIFIED. It would be great if there was also a possibility to automatically send a mail to staff when a patron first creates a request. As ashimema said (paraphrasing here): it would be good to generally add hooks and tie them to the status field so that any status change of an ILL request triggers the corresponding ILL_REQUEST_NEWSTATUS notice if it exists (where NEWSTATUS stands for the new status after the status has changed). Some status changes for instance: ILL_REQUEST_NEW -> sent when request is first created. ILL_REQUEST_CANCEL -> same as it is now, sent when patron wishes to cancel a request ILL_REQUEST_IN_DELIVERY -> sent when status changes to "in delivery". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 36702] New: Background Jobs:Add option to retry failed jobs with a max tries parameter
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36702 Bug ID: 36702 Summary: Background Jobs:Add option to retry failed jobs with a max tries parameter Change sponsored?: --- Product: Koha Version: unspecified 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: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently the background jobs just fail. It would be helpful if there was a path to add or set background jobs with a parameter to retry x times (probably with a y seconds interval between?) especially now that plugins can add background jobs. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 57

[Bug 17787] New: Suppressed items seems so still be included in number of search results
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17787 Bug ID: 17787 Summary: Suppressed items seems so still be included in number of search results Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: viktor.sarge(a)regionhalland.se QA Contact: testopia(a)bugs.koha-community.org We have a use case where like 99% of the collection is hidden and only a few selected items are displayed in the opac (by showing their covers up front on the main page). When going to the detail page and clicking the link for an author that has a long list of records (but only one visible in the opac) I might get indication of 63 hits in the search results and a the links to pages 1,2,3 etc for search results. Only problem is that there is actually only one result since the rest are suppressed. My guess is that the code calculating the number of hits and creating links to the pages of search results is not talking to the suppression system. I could not find any open bugs about this. Perhaps because our use of suppression is a bit of a edge case(?) I ended up "solving" the problem by removing the links on author etc. since we don't use search anyhow. I'll likely not research the issue further, but I felt I should at least report it and keep an eye out. All input is welcome. -- You are receiving this mail because: You are watching all bug changes.

1 30

[Bug 8127] Most-circulated items report doesn't work when limited by library
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8127 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to stable |Needs documenting -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43749] New: 2FA setup to support code to email as well as using authentication applications
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43749 Bug ID: 43749 Summary: 2FA setup to support code to email as well as using authentication applications Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: hdunne-howrie(a)westminster.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- It should be possible to enable 2FA using only an email address as opposed to requiring a separate device and authentication application. Once 2FA is set up, staff can choose 'email code' instead of using an authenticator app. We want this functionality extended to the 2FA setup steps so something who does not have a separate device (only email) can enable 2FA for themselves. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 8127] Most-circulated items report doesn't work when limited by library
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8127 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)|26.11.00,26.05.03,25.05.14 |26.11.00,26.05.03,25.11.08, released in| |25.05.14 --- Comment #17 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> --- Was pushed in 25.11.08 and not reported here (needed for 42736) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 34142] New: Add column sub_location to items table
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34142 Bug ID: 34142 Summary: Add column sub_location to items table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org We should add new column sub_location to items and deleteditems table. This can be used to indicate e.g. if item has some other more specific location than permanent location. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 49

[Bug 43267] New: Batch operations from datatables report view should only send visible results (same as standard view)
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43267 Bug ID: 43267 Summary: Batch operations from datatables report view should only send visible results (same as standard view) Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Depends on: 42190 Target Milestone: --- Created attachment 203428 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203428&action=e… Screenshot showing 'Batch operations with....' button from reports datatables view Sending results to batch operations from the new datatables report view should only send visible results (that is, it should work the same way as sending results from the standard report view). Staff can send *visible* results to batch operations from a report that contains columns for borrowernumber, biblionumber, itemnumber, or cardnumber. However, when using the new datatables feature, all report results are sent to batch operations, not just the visible results. To add extra confusion, the button for batch operations from the datatables view reads 'Batch operations with [total results number] visible records', even when the default 20 records are visible (see attached screenshot). If I change nothing and send results to batch operations as is, all results (not just the 20 visible) are sent. Only visible results should send to batch operations from the datatable view so that it works the same way as sending results to batch operations from the standard report view. (Or, all report results from the standard view should be sent for batch operations, not only the visible results.) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42190 [Bug 42190] Add datatables to reports -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38