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

[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

[Bug 20678] New: Save draft records without committing them to the catalogue
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '25

14 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20678 Bug ID: 20678 Summary: Save draft records without committing them to the catalogue Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl One of our clients has requested the functionality to be able to save a MARC record as a draft so they can return to continue cataloguing it later. This will be achieved by saving the record to the 'reservoir' in much the same way that staged records are stored in the 'import_*' tables but not in the biblio table. The functionality has been achieved in the first patch I will attach, and unit tests for this will come later. -- You are receiving this mail because: You are watching all bug changes.

1 54

[Bug 37715] New: It should be possible to enable/disable each authentication method on the OPAC and staff client
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '25

14 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37715 Bug ID: 37715 Summary: It should be possible to enable/disable each authentication method on the OPAC and staff client Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When setting up identity provides (OAuth/OpenID) you can enable or disable the provider for the OPAC/Staff client We have the preferences OPACShibOnly and staffShibOnly which will limit everything to Shib It would be nice to instead have a switch for each: OpacEnableLocalLogin OpacEnableCASLogin OpacEnableShibLogin OpacEnableLDAPLogin and staff equivalents additionally - when using identity providers they always add the line: <p>If you do not have an external account, but do have a local account, you can still log in: </p> This needs a class at minimum, but should likely be removed and allow the library to specify the text in loginInstructions html customization -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 31498] New: Allow for custom primary contact method values
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '25

13 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Bug ID: 31498 Summary: Allow for custom primary contact method values Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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 The values in the primary_contact_method dropdown on patron creation/edit are hard coded. Some libraries would like to include custom options in that dropdown. Maybe via Authorized Values? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 36185] New: Add option to enforce time limit on suspended holds
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '25

13 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36185 Bug ID: 36185 Summary: Add option to enforce time limit on suspended holds Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kkrueger(a)cuyahogalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently when you suspend a hold in Koha, you have the choice of adding a suspend until date. If the date is left blank the hold is suspended indefinitely, even if DefaultHoldExpiration system preferences are configured. When the hold is unsuspended after the hold expiration date, it is canceled. Being able to limit the amount of time a hold can be suspended would make the holds timeline clearer to patrons. It would also make determining how many copies are needed to fill holds. This could take the form of a system preference that adds the date limitation into the staff interface. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 39245] New: Preferred name should give option to replace more than first name
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '25

13 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39245 Bug ID: 39245 Summary: Preferred name should give option to replace more than first name Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We have a patron, for example only: Johnathan David Smith. He goes by JD. But the preferred name only replaces the first name. There should be an option to also exclude the middle name. Right now the preferred name shows the patron name as JD David Smith. Should only show JD Smith. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 34989] New: Subscription cannot be added if a control field is set up in "Additional Fields" parameter
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '25

13 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34989 Bug ID: 34989 Summary: Subscription cannot be added if a control field is set up in "Additional Fields" parameter Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: anke.bruns(a)gwdg.de QA Contact: testopia(a)bugs.koha-community.org Subscriptions can't be created because of an HTTP 500 and the following message in the plack error log: "Control fields (generally, just tags below 010) do not have subfields, use data() at /usr/share/koha/lib/Koha/Object/Mixin/AdditionalFields.pm line 68." The workaround by Joubu (many thanks!) in the Koha chat was to look whether in Administration > Additional fields > Table 'subscription' (/cgi-bin/koha/admin/additional-fields.pl?tablename=subscription) a MARC field was present that was a control field (ie. without $ field/subfield separator). We indeed had a 001 configured there with MARC field mode "Get value from MARC record" and Searchable=Yes Removing this solved the problem, but perhaps subscriptions should also work if a control field is configured in the place mentioned above? Another thing is that we are not completely sure if the error was produced when we upgraded from 22.05 or if it was present there as well with the additional field set. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 39974] New: "OpacMoreSearches" HTML customization generates invalid HTML
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '25

13 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39974 Bug ID: 39974 Summary: "OpacMoreSearches" HTML customization generates invalid HTML Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org OpacMoreSearches is supposed to be one or more <li> elements. However, when you save it in HTML customizations, it'll add a <ul></ul> tags around the <li> elements you define. Moreover, when you look at the HTML, you notice how OpacMoreSearches injects a <div> into a <ul>: <ul class="nav" id="moresearches"> <li class="nav-item"></li> <div id="OpacMoreSearches"> <div class="default_item"> <div class="default_body"> <ul> <li><a>New content</a></li> </ul> </div> </div> </div> </ul> While a lot of places where we use HTML customizations can validly inject a <div>, this isn't one of them. We might want to add a way for HTML customizations to just inject content directly without using wrappers. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 25682] New: Style transfers interface to match checkin page
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '25

13 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25682 Bug ID: 25682 Summary: Style transfers interface to match checkin page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED 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 Depends on: 25537 The transfers page has fallen behind the style of the checkin and checkout pages. It should be made to look more consistent. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25537 [Bug 25537] Page reload at branchtransfers.pl loses destination branch -- You are receiving this mail because: You are watching all bug changes.

1 18