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

[Bug 42552] New: Reformat examples for UpdateNotForLoanStatusOnCheckin
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42552 Bug ID: 42552 Summary: Reformat examples for UpdateNotForLoanStatusOnCheckin Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Keywords: Academy Severity: minor 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 CC: anna.leissle(a)bsz-bw.de UpdateNotForLoanStatusOnCheckin includes some usage examples, but they are quite hard to read in the normal font. For example it's very easy to miss the spaces needed in front of the second lines: _ALL: -1: 0 CR: 1: 0 BK -1: 0 If we changed this to <code> it would help readability. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41552] New: Holds are not removed from holds queue when hold is suspended
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41552 Bug ID: 41552 Summary: Holds are not removed from holds queue when hold is suspended 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: 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 If one is not using the real time holds queue, holds are not removed from the queue when suspended. Instead, they remain listed until the next time the cron is run. We should remove holds from the queue immediately when suspended, as we do when a hold is filled. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 41732] New: Default order quantity should be 1 unless items are created on ordering
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41732 Bug ID: 41732 Summary: Default order quantity should be 1 unless items are created on ordering Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: slavashishkin(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org This issue was raised by our local librarians who create a large number of acquisition orders, most of which are for a single copy. With the current behaviour, the quantity field defaults to 0, which means that every new order requires an extra click and a manual edit of the quantity field; otherwise, saving triggers a validation popup. Since the field is already clearly marked as required and visually highlighted, the risk of accidentally overlooking it is quite low. We would like to hear how others see this in practice. Does the current default feel helpful in your workflows, or would a default of 1 make more sense in everyday use? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 6532] Way to move items to another record in batches
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6532 Thibaud Guillot (thibaud_g) <thibaud.guillot(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #198664|0 |1 is obsolete| | --- Comment #50 from Thibaud Guillot (thibaud_g) <thibaud.guillot(a)biblibre.com> --- Created attachment 198751 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198751&action=e… Bug 6532: Way to move items to another record in batches This patch adds a new "Move items in a batch" feature, allowing to move multiple items from one bibliographic record to another in a single operation. Test plan: 1. Apply the patch and restart_all. 2. Open a record with at least 2 items (record A). Open or create a second record (record B). 3. On record A: Edit -> "Move items in a batch". Select 1 item, enter record B's biblionumber, submit. => Job finishes. The item appears on record B, not on record A. 4. Repeat with "Delete source bibliographic records if no items remain" checked and move the last item of record A. => Job finishes. Record A is deleted. 5. Place a biblio-level hold on a record with 2 items (record C). Go to Edit -> "Move items in a batch". => A warning icon appears on each item explaining that biblio-level holds will follow if no items remain. 6. Move only 1 item of record C to record B. => The biblio-level hold stays on record C (still has 1 item). 7. Move the last item of record C to record B. => Job report warns that the biblio-level hold has been automatically transferred to record B. => Confirm: record B now has the hold, record C has none. 8. You can test also with hold at item level. Hold simply follows the item on the new record linked. 9. Try entering a non-existent biblionumber as destination. => Error shown before the job is enqueued. Sponsored-by: Université Côte d'Azur Current status: Signed Off -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 26553] New: Datatables button code is duplicated
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26553 Bug ID: 26553 Summary: Datatables button code is duplicated 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: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Code in prog/js/datatables.js and columns_settings.inc have both the (almost) same code for buttons. Can we avoid that? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 141

[Bug 42549] New: Abilty to filter late orders by funds and library
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42549 Bug ID: 42549 Summary: Abilty to filter late orders by funds and library Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It could be nice to have the ability to filter late orders (acqui/lateorders.pl) according to libraries and funds -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 6532] Way to move items to another record in batches
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6532 Thibaud Guillot (thibaud_g) <thibaud.guillot(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42548 Depends on|42548 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42548 [Bug 42548] Add possibility to list multiple barcodes or one biblionumber on attach item action -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 6532] Way to move items to another record in batches
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6532 Thibaud Guillot (thibaud_g) <thibaud.guillot(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |42548 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42548 [Bug 42548] Add possibility to list multiple barcodes or one biblionumber on attach item action -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 41208] New: Log viewer should use an API or limit max results per search
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41208 Bug ID: 41208 Summary: Log viewer should use an API or limit max results per search Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 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 Koha's log viewer loads all results at one time into a datatable. Large systems can have potentially hundreds of millions of rows. An unconstrained search can easily use up all the RAM even on systems with dozens of gigbytes of memory. Koha should either have a limit of the query and encourage users to limit their query further if the full results cannot be displayed, or we should use the API for paginated results. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 42546] New: Unify language in system preferences that refer to Reply-To addresses
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42546 Bug ID: 42546 Summary: Unify language in system preferences that refer to Reply-To addresses Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: david_liddle(a)sil.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Preface: I acknowledge the utility of using a different form, i.e. "ReplyTo", in variables instead of the official message header term "Reply-To". There are discrepancies in the text of system preferences that refer to Reply-To addresses. They can be found in both the staff interface and in the 'explanation' column of the 'systempreferences' table. These differences can make it difficult to find the relevant preferences/variables. (Some quotes below shortened for brevity.) AcquisitionsDefaultReplyTo UI: "Use the reply-to email address ___ when sending acquisitions order and claim notices. If left empty, it will fall back to the first defined address in the following list: library reply-to, library email, ReplytoDefault, KohaAdminEmailAddress." DB" "Default email address used as reply-to for notices sent by the acquisitions module." AddressForFailedOverdueNotices UI: "If left empty then it will fallback to the first defined address in the following list: Library ReplyTo, Library Email, ReplytoDefault and KohaAdminEmailAddress" DB: "If left empty then it will fallback to the first defined address in the following list: Library ReplyTo, Library Email, ReplytoDefault and KohaAdminEmailAddress" emailLibrarianWhenHoldIsPlaced UI: "The first email address set from this list will be used: library reply-to, library email, ReplytoDefault, KohaAdminEmailAddress." (NOTE: Inconsistent also in "first email address set from this list" versus "first defined address in the following list") DB: "If ON, emails the librarian whenever a hold is placed" (NOTE: No reference to Reply-To or the list.) ExpireReservesAutoFillEmail UI: "If no address is defined here, the email will be sent to the library's reply-to address." DB: "If not defined, Koha will fallback to the library reply-to address" ReplytoDefault UI: "Email address to be set as the replyto in emails:" DB: "The default email address to be set as replyto." SerialsDefaultReplyTo UI: "Use the reply-to email address ___ when sending serial claim notices. If left empty, it will fall back to the first defined address in the following list: Library ReplyTo, Library Email, ReplytoDefault, KohaAdminEmailAddress." DB: "Default email address used as reply-to for notices sent by the serials module." Consistent, accurate language and terminology matters, so I suggest dropping the hyphen only in direct references to variables that do not use it. Otherwise, the term should be represented as "Reply-To" as given in the RFC and as shown in a library's settings. It will improve searches and make recognition faster. (The same could be said for Return-Path.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0