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

[Bug 32602] New: SIP Server doesn't respect IssuingInProcess system preference
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '24

07 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32602 Bug ID: 32602 Summary: SIP Server doesn't respect IssuingInProcess system preference Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org The system preference 'IssuingInProcess' when set to "Don't prevent" means patrons will still be allowed to issue items if their rental charge took the patron over the noissuescharge system preference. However, SIP returns that a patron is fine blocked (even if 'IssuingInProcess' equals "Don't prevent") when they try to issue items that take them over the noissuecharge amount. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 33974] New: Add ability to search biblios endpoint using ISBN
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '24

07 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33974 Bug ID: 33974 Summary: Add ability to search biblios endpoint using ISBN Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com CC: tomascohen(a)gmail.com Currently the biblios endpoint will list biblios, including the fields from the biblioitems table. For outside vendors, there is a need to search by the ISBN to retrieve biblios via an ISBN search -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 20489] New: Prevent DB user login
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '24

07 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20489 Bug ID: 20489 Summary: Prevent DB user login Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Since we have the onboarding tool that create a superlibrarian patron as well as a misc script (misc/devel/create_superlibrarian.pl), we could reject login with the DB user. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46

[Bug 18936] New: Convert issuingrules fields to circulation_rules
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '24

07 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18936 Bug ID: 18936 Summary: Convert issuingrules fields to circulation_rules Change sponsored?: --- Product: Koha Version: master 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 18930 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18930 [Bug 18930] Move lost item refund rules to circulation_rules table -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 226

[Bug 21487] New: Disable CataloguingLog syspref in UNIMARC_sync_date_created_with_marc_biblio.pl
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '24

07 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21487 Bug ID: 21487 Summary: Disable CataloguingLog syspref in UNIMARC_sync_date_created_with_marc_biblio.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Script UNIMARC_sync_date_created_with_marc_biblio.pl edits MARC record to define 099 $c and $d. This should not be registered as a cataloguing change in action_logs table. So script must disable CataloguingLog syspref (if enabled) during its process. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 26268] New: Remove items.paidfor once and for all
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '24

07 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26268 Bug ID: 26268 Summary: Remove items.paidfor once and for all Change sponsored?: --- Product: Koha Version: master 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 18501, 23463, 19919 In bug 19919 we removed all references to setting, unsettling and referring to the paidfor field but we neglected to actually drop the field from the database (I think I intended to do this, but was asking for feedback on the approach before adding the actual db change.. then completely forgot when it went through SO/QA quickly). In bug 23463 we inadvertently re-introduced some of the setting code during a rebase. In bug 18501 we then moved that inadvertently re-introduced setter into Koha::Item->store. We should kill it off once and for all! Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18501 [Bug 18501] Automatic refunds need protection from failure https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19919 [Bug 19919] Writing off a Lost Item Fee marks as "Paid for by patron" https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23463 [Bug 23463] Move C4::Items CRUD subroutines to Koha::Item -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 62

[Bug 24786] New: Allow setting a cash register for a login session
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '24

07 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24786 Bug ID: 24786 Summary: Allow setting a cash register for a login session Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: martin.renvoize(a)ptfs-europe.com Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 23321 If enabled, the cash register associated with any transaction needs to be selected for each and every transaction. One can use a 'branch default' to set the most likely register for all transactions at a branch, but it would be an improvement to also allow for selecting a different till for the entirety of a login session. This enhancement aims to add that ability, allowing for a session register to be selected at any point during a session and override the branch default for that session. One should still be able to override the register per transaction if required. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23321 [Bug 23321] Add 'cash registers' to the accounts system -- You are receiving this mail because: You are watching all bug changes.

1 188

[Bug 34927] New: Adding DMARC compatibility to mailing lists
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '24

07 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34927 Bug ID: 34927 Summary: Adding DMARC compatibility to mailing lists Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Websites, Mailing Lists, etc Assignee: wizzyrea(a)gmail.com Reporter: td-koha-bugs(a)agogme.com QA Contact: testopia(a)bugs.koha-community.org The issue of DMARC support for mailing lists is under consideration again after languishing for a while for time limitation as a recurring topic in Koha IRC development meetings now with Jitsi. There is an interest in knowing the availability and willingness of people who administer the mailing lists to support DMARC compatibility when sending messages from the mailing list to subscribers. Email is still not designed for significant authentication which leads some mailing list subscribers with email addresses on DMARC compliant systems to not receive email from Koha lists. The issue has been raised on the Koha mailing list and a vote has been pending about implementing DMARC for sending messages on the mailing lists. See https://lists.katipo.co.nz/pipermail/koha/2023-February/059036.html . The issue is about how mailing list messages are sent with the mailing list address authenticated and avoid having the mailing list server impersonate the author of the mailing list email message. No one is suggesting blocking mailing list subscribers who do not use DMARC which could be a substantial minority and is unrelated to the problem of mailing list impersonation of the message author. Mailing list impersonation of the message author is what is what mailing lists generally do by default when sending messages and is the problem for DMARC. The easiest way to obtain DMARC compatibility for Mailman 2 or 3 without the risk of breaking the message body for email clients is munging the from header, https://wiki.list.org/DEV/DMARC . MIME wrapping may be more elegant but seems only suitable for a company mailing list which users only read with a company supplied email client. In checking for actual implementations in the world, I did not find anyone reporting the choice of MIME wrapping. Having the message appear as only an attachment with an empty message body in an email client would not be good. Some major webmail provider might have avoided the problem but then break it for everyone for months without a care because it is too small a use case for their attention testing in addition to the issue that the webmail client is merely a gateway for many people. Using forum software as an alternative has been disfavoured by a few people commenting on the mailing list. If people would want forum software, Hyperkitty is part of Mailman 3 and better suited to mailing list compatibility than Discourse or other forum software. See https://lists.katipo.co.nz/pipermail/koha/2023-April/059289.html . -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 28996] New: SendQueuedMessages exit on a bad email 'To' and following messages are never processed.
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '24

06 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28996 Bug ID: 28996 Summary: SendQueuedMessages exit on a bad email 'To' and following messages are never processed. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Depends on: 22343 If there's a bad 'To' field email create die but it isn't caught by SendQueuedMessages. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22343 [Bug 22343] Add configuration options for SMTP servers -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 33223] New: Koha::Patron->notice_email_address isn't consistently used
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '24

06 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33223 Bug ID: 33223 Summary: Koha::Patron->notice_email_address isn't consistently used Change sponsored?: --- Product: Koha Version: unspecified 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 Depends on: 18398, 33192 As highlighted in bug 33192, we're not consistently using the Koha::Patron->notice_email_address method to get our 'to' address for notices. This bug serves to catch the last remaining cases where it's not being used and should be. Copying the list from the above bug, notice_email_address is used in: C4::Auth_With_shibboleth C4::Letters (as the default) C4::Auth - For 2FA C4::Auth_with_ldap C4::Reserves shareshelf.pl memberentry.pl opac-registration-varify.pl two_factor_auth.pl notice.pl memberentry.pl pendingreserves.pl Koha::Ticket Patron::Import.pm suggestion.pl overdue_notices.pl TalkingTech_iteive_outbound.pl notice_unprocessed_suggestions.pm first_valid_email is used in: clubs-tab.tt waiting_holds.inc transferstoreceive.tt opac-sendbasket.pl Koha::SharedContent Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18398 [Bug 18398] CHECKIN/CHECKOUT/RENEWAL don't use AutoEmailPrimaryAddress but first valid e-mail https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33192 [Bug 33192] We should rename 'AutoEmailPrimaryAddress' to 'EmailFieldPrimary' for clarification -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32