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

[Bug 28655] New: new ideas/proposal to enhance pluggability
by bugzilla-daemon＠bugs.koha-community.org 18 Aug '25

18 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28655 Bug ID: 28655 Summary: new ideas/proposal to enhance pluggability Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)trust-box.at QA Contact: testopia(a)bugs.koha-community.org see discussion to 28026 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 27599] New: Fine calculation at checkin should be able reflect return claims
by bugzilla-daemon＠bugs.koha-community.org 15 Aug '25

15 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27599 Bug ID: 27599 Summary: Fine calculation at checkin should be able reflect return claims Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com Depends on: 14697 Here's the existing behavior: 1- checkout item with date due in the past 2- run fines cron to create accruing fine 3- mark item claimed without charging lost fee 4- fines does not change at all when item is marked claimed 5- check item in 6- fine goes from accruing to final as if the claim had never happened If we assume some time passes between step 3 and step 5, that could be a significant difference in the final fine total. Should patrons be charged overdue fines for the period between when an item is Claimed Returned and when it is actually checked in? Should that be configurable per library? Should it in some way depend on the claim resolution status? If we *do* charge the lost fee when an item is marked claimed, then we close the fine at the point of claim and it is not changed if the item is later checked in. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14697 [Bug 14697] Extend and enhance "Claims returned" lost status -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 25318] New: Convert authorities_js.inc to JavaScript file with translatable strings
by bugzilla-daemon＠bugs.koha-community.org 15 Aug '25

15 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25318 Bug ID: 25318 Summary: Convert authorities_js.inc to JavaScript file with translatable strings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Now that we can translate strings in JavaScript we can convert authorities_js.inc into a JavaScript file with language strings updated with the new JS translation function. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 32569] New: CloneSubfield() and CloneField() function can result in duplicate ID's when using the upload cataloging plugin
by bugzilla-daemon＠bugs.koha-community.org 15 Aug '25

15 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32569 Bug ID: 32569 Summary: CloneSubfield() and CloneField() function can result in duplicate ID's when using the upload cataloging plugin Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This problem was exposed when trying to clone 856 fields while using the upload.pl cataloging plugin. To recreate: 1. Edit a framework so that the 856$u uses the upload.pl plugin. 2. Go to a record within that framework using the basic editor. 3. Create and 856u, if you don't already have one. 4. Now try and clone the entire field. Look at the ID on the upload button, it beings with 'buttonDot_tag_856_subfield_u_' 5. Notice that the ID is the same as the one you cloned it from. Because of this you cannot use the 2nd 'upload link'. 6. Save you changes and exit the basic editor. 7. Go back into the editor and the new fields now have a different ID and the upload links work correctly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 32877] New: Fix cataloguing/value_builder/upload.pl
by bugzilla-daemon＠bugs.koha-community.org 15 Aug '25

15 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32877 Bug ID: 32877 Summary: Fix cataloguing/value_builder/upload.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: trivial Priority: P5 - low Component: Cataloging Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Blocks: 30975 This is part of the refactoring happening in bug 30975 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30975 [Bug 30975] Framework plugins do not work on cloned fields/subfields -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 30975] New: Framework plugins do not work on cloned fields/subfields
by bugzilla-daemon＠bugs.koha-community.org 15 Aug '25

15 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30975 Bug ID: 30975 Summary: Framework plugins do not work on cloned fields/subfields Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: major Priority: P5 - low Component: Cataloging Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 29155 Since bug 29155 (Upgrade jquery version to 3.6.0) framework plugins do not work on a cloned field/subfield. That is because we rely on jQuery's `.data('events')` to clone event handlers to the cloned elements, and that was removed in jQuery 1.8.0 (I did not confirm but it's possible it continued to work after that thanks to jQuery Migrate) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29155 [Bug 29155] Upgrade jquery version to 3.6.0 -- You are receiving this mail because: You are watching all bug changes.

1 233

[Bug 33575] New: Add table settings to hold_table on /reserve/request.pl
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '25

14 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33575 Bug ID: 33575 Summary: Add table settings to hold_table on /reserve/request.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some libraries who have lots of holds on a single bib would like to be able to sort/search/filter that table. We should make it a dataTable with table settings. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 36846] New: Collected and change variables are set to 0.00 when printing from POS Transaction history
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '25

14 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36846 Bug ID: 36846 Summary: Collected and change variables are set to 0.00 when printing from POS Transaction history Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org TO recreate: 1. Configure your Koha to enable the point of sale system (i.e. enable syspref, set up a register, set up an item to sell). 2. Complete a transaction in the POS system. 3. Go to Cash summary for { THIS BRANCH } 4. Click on the line with a link that includes your register name. ( /cgi-bin/koha/pos/register.pl?registerid=X ) 5. Click 'Print receipt'. 6. Tendered ( collected ) and Change ( change ) are 0.00 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 36115] New: Improve documentation for Return-Path (branches.branchreturnpath)
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '25

14 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36115 Bug ID: 36115 Summary: Improve documentation for Return-Path (branches.branchreturnpath) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org I am not sure if the code or the documentation is the problem here, but let's start with the documentation. For reference, the manual says this today: Email: the email address field is not required, but it should be filled for every library in your system - Note: Be sure to enter a library email address to make sure that notices are sent to and from the right address - Note: If no email address is entered here, the address in the KohaAdminEmailAddress system preference will be used to send notices from this library Reply-To: you can enter a different ‘Reply-To’ email address. This is the email address that all replies will go to. - Note: If no email address is entered here, the address in the ReplytoDefault system preference will be used to receive replies to this library Return-Path: you can enter a different ‘Return-Path’ email address. This is the email address that all bounced messages will go to. - Note: If no email address is entered here, the address in the ReturnpathDefault system preference will be used to receive bounced messages from this library. https://koha-community.org/manual/latest/en/html/administration.html#adding… Mu scenario is as follows: We host Koha for a number of libraries that want to send messages to their patrons by email. For some libraries we can't send email through their SMTP for different reasons. So we set up a noreply address with a domain that we control, so that we can use that as the sender of the emails, and we can do our best to set up SPF, DKIM etc for it, so it won't be seen as spam by services such as Gmail. Based on the description above, I set it up like this: Email = noreply Reply-To = real library email Return-Path = real library email But it turns out that when postfix was processing the email, and passing it on to our SMTP server, it was seeing the "real library email" from the Return-Path setting as the "from" address, not the "noreply" address that we wanted it to see. So the question is: - Is the code wrong in using the Return-Path address as the "from" address? - Or is the documentation wrong in saying that the Return-Path is just for bounced messages? See also: Bug 28729 - Return-path header not set in emails -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 36273] New: ILL - Refactor $op in ill-requests.pl
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '25

14 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36273 Bug ID: 36273 Summary: ILL - Refactor $op in ill-requests.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com CC: pedro.amorim(a)ptfs-europe.com Depends on: 36241, 36243, 36245, 36249 With bug 34478, presenting a form page should be a GET request without 'cud-' in the op URL parameter. Additionally, a form that creates, updates or deletes some object should be a POST with the 'cud-' prefix. ill-requests.pl did not do this distinction originally, and still doesn't. It instead works around 'cud-' in the $op to preserve existing functionality. It should be refactored to better distinguish between a GET $op and a POST $op. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36241 [Bug 36241] ILL Batches are broken https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36243 [Bug 36243] ILL "Edit request" action is broken https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36245 [Bug 36245] ILL - Custom backend form action is broken https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36249 [Bug 36249] ILL - "Request from partners" action is broken -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9