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

[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 37251] New: Default values should be applied when cataloging using the advanced cataloging editor (rancor)
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37251 Bug ID: 37251 Summary: Default values should be applied when cataloging using the advanced cataloging editor (rancor) Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 36272] New: Exporting too many items from item search to barcode file gives "Request-URI Too Long"
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36272 Bug ID: 36272 Summary: Exporting too many items from item search to barcode file gives "Request-URI Too Long" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org To reproduce in KTD: - Login to the staff client - Go to "Item search" - Click on "Search" without adding any limitations - Change to "Show [All] entries" - this should show about 961 items - Click on "Select visible rows" - Click on "Export selected results (961) to" and choose "Barcode file" - This should result in this error: Request-URI Too Long The requested URL's length exceeds the capacity limit for this server. The URL of the page that shows the error looks like this: http://localhost:8081/cgi-bin/koha/catalogue/item-export.pl?format=barcodes… etc etc The solution is probably to do a POST, not a GET? Similar to bug 32278, but in a different area. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10