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

[Bug 10326] bulkmarcimport.pl turns off CataloguingLog sys pref
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '24

07 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10326 Fridolin Somers <fridolin.somers(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=36013 -- You are receiving this mail because: You are watching all bug changes.

1 0

[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

[Bug 11583] Add WYSIWYG editor for HTML notices/letters
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '24

06 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11583 Christopher Brannon <cbrannon(a)cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbrannon(a)cdalibrary.org Status|RESOLVED |REOPENED Resolution|WISHLIST |--- --- Comment #5 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- I would like to see this. If we select HTML in the template, we should be able to see it and format with tools like we can everywhere else. This would be a very welcome enhancement. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 2635] Allow validation of price related item fields
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '24

06 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2635 --- Comment #10 from Chris Nighswonger <cnighswonger(a)foundations.edu> --- (In reply to Esther Melander from comment #9) > To be clear, would this bug validate the 952$g (Cost, normal purchase price) > and 952$v (Cost, replacement price)? > > Bug 34169 added validation of monetary fields in acquisitions, but it did > not include the item form used in acquisitions. In general it would be nice > if it was included both in acquisitions and when editing/adding an item > record to a bibliographic record. In another four years this bug will turn 20... wow! I really do not recall much of anything about this as it has been so long. Reading back, it appears that work I did for LL never made it into the public repo. Sad. Maybe someone currently working on the project can comment. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 2635] Allow validation of price related item fields
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '24

06 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2635 Esther Melander <esther.melander(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |esther.melander@bywatersolu | |tions.com --- Comment #9 from Esther Melander <esther.melander(a)bywatersolutions.com> --- To be clear, would this bug validate the 952$g (Cost, normal purchase price) and 952$v (Cost, replacement price)? Bug 34169 added validation of monetary fields in acquisitions, but it did not include the item form used in acquisitions. In general it would be nice if it was included both in acquisitions and when editing/adding an item record to a bibliographic record. -- You are receiving this mail because: You are watching all bug changes.

1 0