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

[Bug 35049] New: Add ability to choose which status is included in MaxOpenSuggestions
by bugzilla-daemon＠bugs.koha-community.org 05 May '25

05 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35049 Bug ID: 35049 Summary: Add ability to choose which status is included in MaxOpenSuggestions Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org This is following a discussion between me and Aude on https://gitlab.com/koha-community/koha-manual/-/merge_requests/739 A client asked me if their custom status was included in the count for MaxOpenSuggestions. After testing, I found that only "Pending" suggestions were counted. This was fine with my client as it is what they wanted. But Aude raised the question that maybe some libraries might want their custom statuses to be included in the count. My client did ask me in the inital request that if the suggestions with custom statuses were included in MaxOpenSuggestions, if it was possible to "add an exception" to make it not count... I think it depends on the workflow of the library. If the status is s step after the suggestion has been analysed and decided upon, it probably should not count in MaxOpenSuggestions. But if it's a status for open suggestions waiting for analysis by another staff member (for example), it probably should count. I was thinking a system preference might be added, similar to the ILLHiddenRequestStatuses syspref, to let the library choose which statuses count in MaxOpenSuggestions. By default, only 'Pending' counts. To test: 1. Change MaxOpenSuggestions to 2 2. Go to Adminsitration > Authorized values > SUGGEST_STATUS and add a custom status 3. Log in to the OPAC as a patron 4. Make 2 suggestions --> A message should indicate that you cannot make any more suggestions as you have reached the maximum permitted 5. In the staff interface, go to Acquisitions > Suggestions 6. Change the status of one of the suggestions to the custom status 7. Go back to the OPAC --> You should now be able to make a suggestion -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 18298] New: Enforce password complexity
by bugzilla-daemon＠bugs.koha-community.org 05 May '25

05 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18298 Bug ID: 18298 Summary: Enforce password complexity Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Patrons Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some libraries would want to add the option to Koha to enforce a strong password policy. That policy would mean that passwords should include both upper and lower case characters one or more numbers. -- You are receiving this mail because: You are watching all bug changes.

1 91

[Bug 13664] Add password strength plugin
by bugzilla-daemon＠bugs.koha-community.org 05 May '25

05 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13664 Jonathan Druart <jonathan.druart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also|https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=18298 | --- Comment #77 from Jonathan Druart <jonathan.druart(a)gmail.com> --- (In reply to Martin Renvoize (ashimema) from comment #76) > > *** This bug has been marked as a duplicate of bug 18292 *** I guess you meant bug 18298. *** This bug has been marked as a duplicate of bug 18298 *** -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38651] New: Koha MARC Framework Issue: Default Framework Fields Loading Instead of Selected Custom Framework (24.05)
by bugzilla-daemon＠bugs.koha-community.org 05 May '25

05 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38651 Bug ID: 38651 Summary: Koha MARC Framework Issue: Default Framework Fields Loading Instead of Selected Custom Framework (24.05) Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mehmet.akgul(a)mirakil.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hello Koha Community, I am encountering an issue related to MARC framework behavior in Koha version 24.05. Here is the detailed explanation of the problem: Background: We have a custom framework called Kitap Çerçevesi (MRB), which is assigned to all of our bibliographic records. The frameworkcode field in the biblio table confirms that all records are linked to the MRB framework. No records use the Default Framework (Varsayılan Çerçeve). Issue Description: When I edit a bibliographic record, the MRB framework is shown as selected in the "Change framework" dropdown menu. However, the fields displayed in the editing interface are from the Default Framework (Varsayılan Çerçeve), not from MRB. This behavior persists even though the records are correctly assigned to the MRB framework in the database. What We Tried: Ensured that all records are linked to MRB in the frameworkcode field. Attempted to reconfigure and minimize the Default Framework's fields to ensure MRB would load correctly. Restarted the Koha services (Plack, Apache). Exported and re-imported the MRB framework to refresh its configuration. Checked log files (plack-error.log) but did not find any related errors. Observed Behavior: The editing interface always loads the fields from the Default Framework (Varsayılan Çerçeve), regardless of the selected framework. Selecting MRB again from the dropdown menu does not refresh the fields to the correct framework. Steps to Reproduce: Create a bibliographic record using a custom framework (e.g., MRB). Save and edit the record. Observe that the fields loaded in the editing interface belong to the Default Framework instead of the custom framework, even though the dropdown menu indicates the custom framework is selected. Request for Help: Is this a known issue or bug in Koha 24.05? Are there any configuration changes or patches that can resolve this behavior? If this is not a bug, could you suggest any solutions or workarounds to force Koha to load the correct framework fields in the editing interface? Thank you for your help and support! Best regards Mehmet Faruk Akgul Mirakil Data Processing -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 33985] New: Add the ability to integrate electronic signatures
by bugzilla-daemon＠bugs.koha-community.org 05 May '25

05 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33985 Bug ID: 33985 Summary: Add the ability to integrate electronic signatures 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: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com A library would like to be able to integrate electronic signatures into Koha. This could be a way that the patron could sign digitally and this signature would be captured in Koha. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 39813] New: z3950_responder.pl needs support for authentication
by bugzilla-daemon＠bugs.koha-community.org 05 May '25

05 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39813 Bug ID: 39813 Summary: z3950_responder.pl needs support for authentication Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl At the moment, z3950_responder.pl only provides anonymous access via Z39.50. That means if you want to restrict your Z39.50 endpoint using a username and password, you're forced to use Zebra. If z3950_responder.pl had support for authentication, then it would be one more nail in the coffin for Zebra, as you wouldn't need Zebra for that use case anymore. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 39819] New: Additional performance improvements for when loading borrower relationships.
by bugzilla-daemon＠bugs.koha-community.org 05 May '25

05 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39819 Bug ID: 39819 Summary: Additional performance improvements for when loading borrower relationships. Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 >From Nick via Bug 39644: I think there is more cleanup to be done here. relationships_debt is only called twice in the code base: once in moremember.pl once in Koha::Patron->is_patron_inside_charge_limits (which is also called in moremember) The two calls are: - moremember: $patron->relationships_debt( { include_guarantors => 0, only_this_guarantor => 1, include_this_patron => 1 } ); - is_patron_inside_charge_limits: $patron->relationships_debt( { include_guarantors => 1, only_this_guarantor => 0, include_this_patron => 1 } ); The difference being that the first returns only the single patrons fine + their guarantees, the latter returns the patron and thier gusarantees and the guarantees other guarantors The first being a subset of the second, we should be able to return this additional info from "is_patron_inside_charge_limits" and avoid a double call. Additionally, moremember does checks against "NoIssuesChargeGuarantorsWithGuarantees" and "NoIssuesChargeGuarantees" - both of which are checked inside "is_patron_inside_charge_limits" so we can simply use values we are already calculating and not calculate them again -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 35832] New: Add option to include an email signature on all notices
by bugzilla-daemon＠bugs.koha-community.org 04 May '25

04 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35832 Bug ID: 35832 Summary: Add option to include an email signature on all notices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org It would be useful to have the option to always include a particular signature on all notices from the system. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 38747] New: Have consistent signature in sample notices
by bugzilla-daemon＠bugs.koha-community.org 04 May '25

04 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38747 Bug ID: 38747 Summary: Have consistent signature in sample notices Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org We currently have a plethora of signature styles across sample notices. It would be nice to make them consistent. Here are the ones I found in the sample_notices.yaml file (I skipped the slips and sms messages) Notices meant for patrons - branchname Staff (ODUE) - Kind regards branchname (BOOKING_CANCELLATION, BOOKING_MODIFICATION, BOOKING_CONFIRMATION) - Kind regards full branch address (ILL_PICKUP_READY, ILL_REQUEST_UNAVAIL, ILL_REQUEST_UPDATE, ILL_PICKUP_READY, ILL_REQUEST_UNAVAIL) - Thank you (TICKET_ACKNOWLEDGE, TICKET_RESOLVE, TRANSFER_OWNERSHIP) - Thank you, branchname (ACCEPTED, AVAILABLE, ORDERED, REJECTED) - Thank you, Librarian branchname (MEMBERSHIP_EXPIRY) - Thank you, Your library, branchname (MEMBERSHIP_RENEWED) - Thank you. (CHECKIN, DUEDGST, PREDUEDGST, PASSWORD_RESET,STAFF_PASSWORD_RESET) - Thank you. Your library. (SHARE_ACCEPT, SHARE_INVITE) - Thank you! (AR_COMPLETED, AR_PENDING, AR_REQUESTED, AR_PROCESSING, HOLDDGST, RETURN_RECALLED_ITEM, PICKUP_RECALLED_ITEM, HOLDPLACED_PATRON) - Thank you for visiting branchname. (CHECKOUT, RENEWAL) - Your library. (ACQ_NOTIF_ON_RECEIV, PASSWORD_CHANGE) - Your library (AR_CANCELED, 2FA_DISABLE) - No signature (ACCOUNT_PAYMENT, ACCOUNT_WRITEOFF, DUE, PREDUE, DISCHARGE,OPAC_REG_VERIFY, WELCOME, 2FA_OTP_TOKEN, CANCEL_HOLD_ON_LOST, HOLD, HOLD_REMINDER, NEW_CURBSIDE_PICKUP, SERIAL_ALERT, AUTO_RENEWALS, AUTO_RENEWALS_DGST, LIST, CART) Notices meant for staff, other libraries, vendors, etc. - Thank you (TICKET_ACKNOWLEDGE, TICKET_RESOLVE) - Thank you, branchname (ACQORDER, TO_PROCESS, NOTIFY_MANAGER) - Kind regards full branch adress (ILL_PARTNER_REQ) - Your library (2FA_DISABLE) - No signature (TICKET_ASSIGNED, TICKET_NOTIFY, CHECKOUT_NOTE, ACQCLAIM, ILL_REQUEST_CANCEL, ILL_REQUEST_MODIFIED, ILL_REQUEST_CANCEL, ILL_REQUEST_MODIFIED, HOLDPLACED, HOLD_CHANGED, NEW_SUGGESTION, PROBLEM_REPORT, OPAC_REG, OAI_HARVEST_REPORT) Is there any that would fit all of them? I like "Thank you, branchname" provided the branch is available for the notice. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 38090] New: The UX for customer notice styling per notice template is confusing
by bugzilla-daemon＠bugs.koha-community.org 02 May '25

02 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38090 Bug ID: 38090 Summary: The UX for customer notice styling per notice template is confusing Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org A couple of people have highlighted now that the adding of a 'Format' section amongst the message transport types in the notice template editor is confusing. The feature itself is also a little misleading as people presumed from the title that it affected print-type notices only, when in fact it affects all notice types when printed. The distinction is subtle, but makes a large difference in expectations. I'm not sure how to proceed here, but I want it recorded as a bug to see if anyone can come up with a cleaner approach for end users. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14