December 2023 - Koha-bugs - lists.koha-community.org

[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 07 Feb '24

07 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 07 Feb '24

07 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 32137] New: Resend notices with updated info
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '24

06 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32137 Bug ID: 32137 Summary: Resend notices with updated info 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org When you resend a notice, it seems to simply resend using the same info it used before. This is pointless. If the number or e-mail address was bad to begin with, why are we resending to the same? Many times we can correct issues with numbers or addresses, or we change HOW the patron receives a notice. We should be able to resend the notice based on current info in the patron record. This would be much more useful. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 35074] New: Add --patron_category to writeoff_debts.pl
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '24

06 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35074 Bug ID: 35074 Summary: Add --patron_category to writeoff_debts.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Depends on: 27049 It would be helpful to allow limiting by patron category in the writeoff_debts script. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27049 [Bug 27049] Add a script to bulk writeoff debts -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 31732] New: 880 titles missing from OPAC checkout summary
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '24

06 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31732 Bug ID: 31732 Summary: 880 titles missing from OPAC checkout summary Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org We're showing 880 $6245 values on the search results and the detail page, so we should show them on the OPAC user checkout summary page too. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 23033] New: C4::Items::AddItemBatchFromMarc does not queue bib record for indexing
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '24

05 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23033 Bug ID: 23033 Summary: C4::Items::AddItemBatchFromMarc does not queue bib record for indexing Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul(a)flo.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Callers of C4::Items::AddItemBatchFromMarc must call ModZebra (directly or indirectly) afterwards, which strikes me as wrong. AddItemBatchFromMarc used to call C4::Biblio::ModBiblioMarc, which calls C4::Items::ModZebra[*] but the call to ModBiblioMarc was commented out in commit 3584c442 (2010-09-03 12:16:52 +0200, see bug #5579) and the comment was never removed. The only code in Koha 18.11 that calls AddItemBatchFromMarc is in migration_tools/bulkmarcimport.pl, which dutifully calls MobBiblioMarc once after each call to AddItemBatchFromMarc -- even(!) if AddItemBatchFromMarc fails, which seems weird but I don't fully understand the code. We could add a call to ModZebra in AddItemBatchFromMarc but I assume it would be better to reinstate the call to ModBiblioMarc. I'll attach a patch shortly. [*] C4::Items gets ModZebra from C4::Biblio, which implements and exports it, so my will also change this to a call to C4::Biblio::ModZebra. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 24710] New: patron-title.inc should have seperate span classes for firstname, othername, surname
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '24

04 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24710 Bug ID: 24710 Summary: patron-title.inc should have seperate span classes for firstname, othername, surname 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 Some libraries would prefer to be able to customize how the name is displayed in the patron details. If these included <span> classes we could easily move/hide/reorder bits we don;t want. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 34699] New: add a notforloan_on column in items table to store the date of last notforloan change
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '24

02 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34699 Bug ID: 34699 Summary: add a notforloan_on column in items table to store the date of last notforloan change 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: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It could be useful to add a notforloan_on column in items table to store the date of last notforloan change. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 34950] New: ILS DI Availability is not accurate for items on holds shelf or in transit
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '24

02 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34950 Bug ID: 34950 Summary: ILS DI Availability is not accurate for items on holds shelf or in transit Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: blawlor(a)clamsnet.org QA Contact: testopia(a)bugs.koha-community.org The ILS DI web service is a handy way for a third party system, such as a mobile app, to check for the availability of items for a given bib record in your system. If you make a call like https://{OPAC_DOMAIN}/cgi-bin/koha/ilsdi.pl?service=GetAvailability&id={BIB_ID}&id_type=bib the response shows the availabilitystatus of items that are on the holds shelf or in transit as 'available'. While these items may be technically available to be checked out, it's not ideal to send the message to patrons that these items are available because they may show up at the library to get the book and be disappointed :( It would be more accurate and informative if ILS DI could show availabilitystatus 'not available' with availabilitymsg indicating 'on hold shelf' or 'in transit' for these items. Alternatively it would be nice to have a REST API endpoint for item availability to easily get this info to third party developers. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21