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

[Bug 31370] New: Additional contents: Preview of default content only
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '25

19 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31370 Bug ID: 31370 Summary: Additional contents: Preview of default content only 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I noticed this while testing bug 29782. I think the root problem is the same, but the problem it causes is minor compared to the created items not showing up at all. When only the language tabs are filled, the preview modal is empty. To test: 1) In a multilanguage installation, go to Tools > HTML customizations 2) Click "New entry" 3) Do not fill the "Default" tab, fill only the language tabs (title and content) 4) Save 5) Click "Preview content" It will say "Preview of" followed by empty title (default title) and empty content (default content). I'm not sure what we would want to appear? All languages one after the other? A tabbed modal (is that possible?)? Different preview buttons? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 25161] New: Can not edit relationship or guarantee of guarantor from the guarantee form
by bugzilla-daemon＠bugs.koha-community.org 18 Aug '25

18 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25161 Bug ID: 25161 Summary: Can not edit relationship or guarantee of guarantor from the guarantee form Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com With the introduction of multiple guarantors to guarantees, bug 14570, now in 19.11, the relationship can not be edited from the guarantee from. Previously, a relationship and the actual guarantor could be edited from the guarantee form. Now in 19.11, there is no way to edit or change the guarantor from the guarantee form. The option that exists in 19.11 is to remove the guarantor not to edit. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[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 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