A new request with request id 7235 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is :
Title : Koha-devel Digest, Vol 202, Issue 16
Category :
Description : Send Koha-devel mailing list submissions to
koha-devel@lists.koha-community.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
or, via email, send a message with subject or body 'help' to
koha-devel-request@lists.koha-community.org
You can reach the person managing the list at
koha-devel-owner@lists.koha-community.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Koha-devel digest..."
Today's Topics:
1. Re: Handling normalized phone number data
(dcook@prosentient.com.au)
2. Re: Handling normalized phone number data
(dcook@prosentient.com.au)
----------------------------------------------------------------------
Message: 1
Date: Thu, 15 Sep 2022 10:31:34 +1000
From: <dcook@prosentient.com.au>
To: "'Kyle Hall'" <kyle@bywatersolutions.com>
Cc: "'koha-devel'" <koha-devel@lists.koha-community.org>, "'Tomas
Cohen Arazi'" <tomascohen@theke.io>, "'Martin Renvoize'"
<martin.renvoize@ptfs-europe.com>
Subject: Re: [Koha-devel] Handling normalized phone number data
Message-ID: <1a8901d8c89a$8f722190$ae5664b0$@prosentient.com.au>
Content-Type: text/plain; charset="utf-8"
Glad to hear other folk are interested to store numbers in E.164 too! Like you say, we’re already doing it for SMS numbers, so I think it makes sense to do it for all phone numbers. Kyle, what do you think about my Koha::Patron->phone() method for doing that?
I was thinking how it would be nice to format them for display, but it’s probably easier said than done.
For instance, in Australia, we have several different formats (https://www.stylemanual.gov.au/grammar-punctuation-and-conventions/numbers-and-measurements/telephone-numbers):
* 0412 345 678 (mobile)
* 02 1234 5678 (landline)
* 1300 123 456 (nation-wide local rate number)
* 13 00 00 (alternative nation-wide local rate number)
It looks like Number::Phone doesn’t support Australian numbers and Number::Phone::Normalize looks old/simple.
David Cook
Senior Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
From: Kyle Hall <kyle@bywatersolutions.com>
Sent: Wednesday, 14 September 2022 8:26 PM
To: dcook@prosentient.com.au
Cc: koha-devel <koha-devel@lists.koha-community.org>; Tomas Cohen Arazi <tomascohen@theke.io>; Martin Renvoize <martin.renvoize@ptfs-europe.com>
Subject: Re: Handling normalized phone number data
Storing numbers in E.164 makes sense to me! We already enforce it for SMS numbers, so it would make sense to extend this to all other phone numbers. It would then be trivial to have a phone number format syspref in the same way we have a date format syspref. For searching it would be as simple as stripping all non-numerics from the search term and performing a substring search.
Perhaps Number::Phone or Number::Phone::Normalize would be of use.
Kyle
On Wed, Sep 14, 2022 at 2:43 AM <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > wrote:
Hi all,
I’ve been working lately on https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23817 in an effort to let staff users easily search phone numbers in the Patrons module.
Currently, phone number searching doesn’t work if you have punctuation or other formatting inconsistent with your search query.
So I’m proposing normalizing phone numbers. Normalizing the search query is easy, but normalizing the data in the database is harder. In older versions of Koha, I used SQL to normalize the phone column in the WHERE clause, but that’s seemingly impossible now that we’re using DataTables and the REST API.
So it seems to me the only way forward is to normalize the data in the database. I’ve attached a patch which provides a Koha::Patron->phone() set method which normalizes the phone number before it’s saved in the database, but I don’t know what other Koha folk think about that.
Thoughts?
David Cook
Senior Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
--
Kyle M. Hall
Loose Cannon, ByWater Solutions
<mailto:kyle@bywatersolutions.com> kyle@bywatersolutions.com
<http://bywatersolutions.com/> https://bywatersolutions.com
<http://bywatersolutions.com/what-is-koha/> What is Koha?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220915/eb5d25f2/attachment-0001.htm>
------------------------------
Message: 2
Date: Thu, 15 Sep 2022 10:36:46 +1000
From: <dcook@prosentient.com.au>
To: "'Tomas Cohen Arazi'" <tomascohen@theke.io>
Cc: "'koha-devel'" <koha-devel@lists.koha-community.org>, "'Kyle
Hall'" <kyle@bywatersolutions.com>, "'Martin Renvoize'"
<martin.renvoize@ptfs-europe.com>
Subject: Re: [Koha-devel] Handling normalized phone number data
Message-ID: <1a8e01d8c89b$4464c350$cd2e49f0$@prosentient.com.au>
Content-Type: text/plain; charset="utf-8"
I think at some point both the phone and email details should be moved into their own table(s), and then 1 would get a primary flag.
With the DataTables and REST API, I suppose we could hard-code a join into Koha/REST/V1/Patrons.pm.
If we had a “phone” table, we could potentially store both free-text (potentially formatted) and normalized versions of the phone number. Then we’d just update the patron search to use the normalized version.
But all of that sounds like a lot of effort :/
David Cook
Senior Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
From: Tomas Cohen Arazi <tomascohen@theke.io>
Sent: Wednesday, 14 September 2022 11:10 PM
To: dcook@prosentient.com.au
Cc: koha-devel <koha-devel@lists.koha-community.org>; Kyle Hall <kyle@bywatersolutions.com>; Martin Renvoize <martin.renvoize@ptfs-europe.com>
Subject: Re: Handling normalized phone number data
Should we also think of moving phones to their own table?
El mié, 14 sept 2022 a las 3:43, <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > escribió:
Hi all,
I’ve been working lately on https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23817 in an effort to let staff users easily search phone numbers in the Patrons module.
Currently, phone number searching doesn’t work if you have punctuation or other formatting inconsistent with your search query.
So I’m proposing normalizing phone numbers. Normalizing the search query is easy, but normalizing the data in the database is harder. In older versions of Koha, I used SQL to normalize the phone column in the WHERE clause, but that’s seemingly impossible now that we’re using DataTables and the REST API.
So it seems to me the only way forward is to normalize the data in the database. I’ve attached a patch which provides a Koha::Patron->phone() set method which normalizes the phone number before it’s saved in the database, but I don’t know what other Koha folk think about that.
Thoughts?
David Cook
Senior Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
--
Tomás Cohen Arazi
Theke Solutions (http://theke.io)
✆ +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220915/2d4c4898/attachment.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/
------------------------------
End of Koha-devel Digest, Vol 202, Issue 16
*******************************************
NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.