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

[Bug 32403] New: On Demand Messaging
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '26

28 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32403 Bug ID: 32403 Summary: On Demand Messaging Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: christofer.zorn(a)ajaxlibrary.ca QA Contact: testopia(a)bugs.koha-community.org We are a library that relies on both email messaging (through Koha) along with SMS and Phone messaging (through Twilio). We are very happy with the messaging features involved in Koha, but for me, there is something missing that could be improved. With the right system permissions, we'd like to see the ability to generate on demand messages to specific patrons, or even tailored messages to groups. While I understand that this isn't specifically what Koha is meant for, there are wider benefits to this that I think warrant a discussion. This is a means of interacting with a patron. While individual email is normally an option, in a mid to larger sized system where multiple staff can reply to a communal message, Koha has a tracking mechanism that would allow staff to see what information was sent to a patron by looking at the Notice tab. This could also morph into a marketing aspect of Koha where we could leverage the history and make this similar to Patron Point. Symphony has an on demand message sending tool, however from what I remember it was spotty. The tweak would be creating an interface that allowed inputting of information into the messaging table ... Please let me know if this is possible. Our library has had the need for this a couple of times, where we could take one last stab at reaching out to expired patrons (beyond what Koha is already doing), or communicating back to a patron through SMS when leaving a voicemail isn't an option. Thanks! Chris -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 31659] New: Add SMSAlertNumber to options in borrowers.primary_contact_method
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '26

28 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31659 Bug ID: 31659 Summary: Add SMSAlertNumber to options in borrowers.primary_contact_method 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: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 11879 The primary contact method field added in bug 11879 is set via a dropdown the options in which contain all of the phone and email fields from the borrowers table that are not hidden via BorrowerUnwantedField. It should also include an option for SMS Alert Number if the library is not hiding the field. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11879 [Bug 11879] Add a new field to patron record: main contact method -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 31572] New: E-mail and SMS verification
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '26

28 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31572 Bug ID: 31572 Summary: E-mail and SMS verification Change sponsored?: --- Product: Koha Version: 21.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 I believe Koha has a basic level of e-mail verification with patrons that self register, but it would be helpful if there were a verification method for e-mail and SMS on both staff and patron sides. The idea is, that when an e-mail address or SMS number is entered by staff or patron, there would be a button next to each that would say something like 'Verify'. Staff or patron would click the button, and a link is sent to the e-mail address or number with an explanation (instantly, not through a queue). If the patron clicks the link within a specified amount of time, the button next to that address or number goes away, replaced by the word 'Verified!'. Until the number or address is verified, notices will not go through that method. Notices would only go out through methods that are setup and verified. A step further would be to have another button next to it on the staff side that would be something like 'Re-verification Request'. If staff get bounced e-mails or texts, it would put the address or phone number back to a verification needed mode, and stop all notifications through that method until verified again. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 30166] New: SMS Number
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '26

28 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30166 Bug ID: 30166 Summary: SMS Number Change sponsored?: --- Product: Koha Version: unspecified 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 Having worked with two variations of SMS Delivery, I think we could simplify SMS setup for the staff/patron. Instead of just filling in a phone number, what if the SMS number gave the following options: 1) Use the primary number 2) Use the secondary number 3) Provide a unique number. The third option could reveal a new text box to put a number in. Honestly though, I think we could get by with just using the primary or secondary number fields. I also think that in the SMS setup, you could select from popular services, and have Koha format the number as needed. If using e-mail, it strips out all non-numbers and checks that the number is the correct length. If Twilio, it makes sure number is stripped of non-numbers and +1 or whatever is added to the beginning. Since different countries have different formats, and phone numbers can be entered in various ways, maybe we could have a custom regex entered to reformat according to your specific uses. The approach that we currently use here is that we have an example format in the SMS number field, and I created an icon to copy the primary phone number, stripping non-numbers and adding a +1 to the beginning. I added another icon to clear the field. It has improved the process vastly. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 30054] New: Add SMS equivalent to EmailOverduesNoEmail
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '26

28 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30054 Bug ID: 30054 Summary: Add SMS equivalent to EmailOverduesNoEmail 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 20076 introduced a new system preference 'EmailOverduesNoEmail' which is great. Koha will still generate a print notice when SMS is selected in overdue notice/status triggers and a patron does not have an smsalertnumber. It would be nice if there was an SMS equivalent system pref like 'SMSOverduesNoSMS' -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 26757] New: SMS Test Button
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '26

28 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26757 Bug ID: 26757 Summary: SMS Test Button 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 It would be great if there were a test button on the staff and opac interfaces for testing the SMS setting to make sure they work, rather than having to wait for a message to trigger, or having to setup a scenario to trigger a notice. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 24374] New: Make SMS-errors from process_message_queue.pl more informational
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '26

28 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24374 Bug ID: 24374 Summary: Make SMS-errors from process_message_queue.pl more informational 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: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org The Debian packages run process_message_queue.pl thusly: koha-foreach --chdir --enabled --email /usr/share/koha/bin/cronjobs/process_message_queue.pl This can result in errors like this in an email to the server admin: Cannot use regional phone numbers with an international driver at /usr/share/koha/lib/C4/SMS.pm line 120. Not very informative... It would be great if we could add the actual SMS number that failed, as well as the name of the Koha instance/site where it came from. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 18823] New: Advanced editor - Rancor - add ability to edit records in import batches
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18823 Bug ID: 18823 Summary: Advanced editor - Rancor - add ability to edit records in import batches Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: nick(a)bywatersolutions.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl These patches allow the use of import batches as targets in the advanced editor -- You are receiving this mail because: You are watching all bug changes.

1 228

[Bug 27648] New: Add itemnumber as an option for moving/attaching an item from one bib to another
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27648 Bug ID: 27648 Summary: Add itemnumber as an option for moving/attaching an item from one bib to another Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When moving an item or order to another bib you must enter the barcode of the item in "attach item." We have found this to be problematic for some items because they are ones that are still on order so they don't have barcodes yet. This means we have to add a barcode to the item record in order to move it. It could be for something we haven't even received yet so we have to add it in order to move it and then delete the barcode because when we do receive it there will be a different barcode attached to it by the vendor. It would be very helpful if we could also use the itemnumber as a way to move the item. It already exists and would be a much more efficient way of performing this function. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 22415] New: Koha::EDI should not use Log::Log4perl directly
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22415 Bug ID: 22415 Summary: Koha::EDI should not use Log::Log4perl directly 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 Target Milestone: --- We have Koha::Logger for instantiating Log4perl loggers now.. it should be used here too. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24