From alexbuckley at catalyst.net.nz  Thu Sep  1 07:39:47 2022
From: alexbuckley at catalyst.net.nz (Alex Buckley)
Date: Thu, 1 Sep 2022 17:39:47 +1200
Subject: [Koha-devel] Enable libraries to moderate OPAC
 self-registrations
In-Reply-To: <a5a23b3b-e50e-ee63-79a0-5a9781baa158@biblibre.com>
References: <16588a0a-a8b9-e4a9-f2de-13d084785a4c@catalyst.net.nz>
 <CABZfb=U7XMt4d3Mf1Vh1Fgm_iuGboUYd62icxbZLn1jqEjfHBw@mail.gmail.com>
 <7d13ac6a-6fec-9526-a514-d1aece591f22@catalyst.net.nz>
 <a5a23b3b-e50e-ee63-79a0-5a9781baa158@biblibre.com>
Message-ID: <84a5b948-29dd-599f-5f07-692d496f1b19@catalyst.net.nz>

Hi Arthur,

Thanks very much for your reply. Very interesting idea!

Are the electronic resources that you hide with Bokeh the links in
biblio 856$u subfields?

To give you some more context, one of the reasons this feature was
proposed was that as soon as patrons have a Koha userid and password
then they could authenticate (via Stunnel/SIP2) to electronic platforms
linked from the OpacNav HTML customisations on the OPAC home page.

Meaning if the OPAC has OPACPublic='Enable' then electronic resource
platform links in HTML customisations would be visible on the OPAC home
page and, therefore, accessible to all users regardless of their patron
category.

Having some ability for libraries to moderate registrations, before
those users have a userid and password, would restrict whether they
could authenticate to these electronic platforms via Stunnel/SIP2.

Thanks,

Alex


On 1/09/22 01:01, Arthur wrote:
>
> Hi Alex (&folks)
>
> What about the electronic ressources uses the Koha
> groups/patron_category to allow or deny access to the resource?
>
> Then if newly created patrons have a specific default category, then
> this category could be denied access to electronic resources.
>
> We've done this way for our frontend software (Bokeh) and it works
> quite well. Upon login, the patron category is received.
>
> Depending on the category, the user can see the links to electronic
> resource or not. Also the electronic resource server checks the
> category against Koha using CAS attributes.
>
> Cheers,
>
> Arthur
>
> On 31/08/2022 06:32, Alex Buckley wrote:
>>
>> Thanks for that Tomas, I appreciate it. I will add a separate
>> table(s) and will have a think about what you have noted.
>>
>> Kind regards,
>>
>> Alex
>>
>>
>> On 31/08/22 14:35, Tomas Cohen Arazi wrote:
>>> Please, use a separate table. And think of the request workflow
>>> handling in the db, the statuses (as enum), how it will be handled
>>> at library or library group level. Even if not implemented at this
>>> stage. Also, maybe you need more than one table, don't fear adding
>>> tables if they make sense and give us a cleaner implementation.
>>>
>>> Moderation should be traceable, etc.
>>>
>>> Thinking of API routes for the process usually clears the design
>>> issues as it points to the classes you will need.
>>>
>>> El lun, 29 ago 2022 19:46, Alex Buckley
>>> <alexbuckley at catalyst.net.nz> escribió:
>>>
>>>     Kia ora/Hello Koha community,
>>>
>>>     I am currently working on reviving bug 25090
>>>     <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25090>
>>>     ( Moderate OPAC self-registrations before a patron account is
>>>     created ).
>>>
>>>     *New proposed functionality:*
>>>
>>>     Step 1: The library enables both the new
>>>     'PatronSelfRegistrationModeration' syspref and the existing
>>>     'OpacResetPassword'syspref.
>>>
>>>     Step 2: When a user submits an OPAC self-registration their Koha
>>>     patron account is not created immediately - i.e. they cannot yet
>>>     log into the OPAC.
>>>
>>>     Step 3: A pending registration link appears at the bottom of the
>>>     staff client home page (like what's currently done with new
>>>     purchase suggestions, or OPAC patron modification requests).
>>>
>>>     Step 4: Librarians can click on the link to go to a page to
>>>     approve or decline the registration.
>>>
>>>     Step 4a: If approved the user is sent an email notice,
>>>     containing their Koha username and an OPAC reset password link.
>>>
>>>     Step 4b: If declined the user is sent a different email notice.
>>>
>>>     *The rationale for adding this feature:*
>>>     You can currently limit the circulation of self-registered
>>>     patrons - by using the PatronSelfRegistrationDefaultCategory
>>>     syspref and creating circulation rule(s) for that category.
>>>
>>>     However, users only need an OPAC login (without the ability to
>>>     circulate) to access electronic content providers (integrated
>>>     with Koha via STunnel/SIP2). Some electronic content providers
>>>     charge libraries based on their usage. Meaning it might not be
>>>     optimal having anyone from around the world self-registering for
>>>     a library OPAC login and accessing electronic content from some
>>>     providers, therefore, incurring extra costs for the library.
>>>
>>>     Bug 25090 was originally developed in the early days of the
>>>     pandemic to ensure new self-registering OPAC users accessing 3rd
>>>     party databases were coming from acceptable locations i.e. they
>>>     were members of the organisation the library is in.
>>>
>>>     More details can be found here:
>>>     https://www.catalyst.net.nz/blog/mental-health-education-resource-library-now-offers-online-self-registration
>>>
>>>     *Questions I would like to hear your thoughts on please:*
>>>
>>>     Q1: Are you in favour of this as a new feature in Koha?
>>>
>>>     Q2: Would you prefer a new database table be added for
>>>     self-registrations awaiting approval, or should I use the
>>>     borrowers_modifications table - as is used by OPAC patron
>>>     modification requests?
>>>
>>>     Q3: How would you envisage this self-registration moderation
>>>     feature fitting in with the existing 
>>>     PatronSelfRegistrationVerifyByEmailand
>>>     PatronSelfRegistrationDefaultCategory sysprefs?
>>>
>>>     Any thoughts much appreciated.
>>>
>>>     Kind regards,
>>>
>>>     Alex
>>>
>>>     _______________________________________________
>>>     Koha-devel mailing list
>>>     Koha-devel at 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/
>>>
>> -- 
>> Alex Buckley
>> Koha Developer | Implementation Lead
>> Catalyst IT - Expert Open Source Solutions
>>
>> Catalyst.Net Ltd - a Catalyst IT group company
>>
>> CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.
>> It may contain privileged, confidential or copyright information. If you are not
>> the named recipient, any use, reliance upon, disclosure or copying of this email
>> or its attachments is unauthorised. If you have received this email in error,
>> please reply via email or call +64 4 499 2267.
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at 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/
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

-- 
Alex Buckley
Koha Developer | Implementation Lead
Catalyst IT - Expert Open Source Solutions

Catalyst.Net Ltd - a Catalyst IT group company

CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.
It may contain privileged, confidential or copyright information. If you are not
the named recipient, any use, reliance upon, disclosure or copying of this email
or its attachments is unauthorised. If you have received this email in error,
please reply via email or call +64 4 499 2267.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220901/ad65bbf6/attachment-0001.htm>

From arthur.suzuki at biblibre.com  Thu Sep  1 14:53:15 2022
From: arthur.suzuki at biblibre.com (Arthur)
Date: Thu, 1 Sep 2022 14:53:15 +0200
Subject: [Koha-devel] Enable libraries to moderate OPAC
 self-registrations
In-Reply-To: <84a5b948-29dd-599f-5f07-692d496f1b19@catalyst.net.nz>
References: <16588a0a-a8b9-e4a9-f2de-13d084785a4c@catalyst.net.nz>
 <CABZfb=U7XMt4d3Mf1Vh1Fgm_iuGboUYd62icxbZLn1jqEjfHBw@mail.gmail.com>
 <7d13ac6a-6fec-9526-a514-d1aece591f22@catalyst.net.nz>
 <a5a23b3b-e50e-ee63-79a0-5a9781baa158@biblibre.com>
 <84a5b948-29dd-599f-5f07-692d496f1b19@catalyst.net.nz>
Message-ID: <4c4653eb-b360-9470-425e-9ed336c76a3e@biblibre.com>

Hi Alex,

In our case (Koha + Bokeh + ArteCampus), being able to authenticate 
against Koha doesn't mean someone would be granted access the resource 
(permissions are managed by ArteCampus).

In our case, any koha user can authenticate and see the link to the 
resource, even non connected users can see the link.

However, ArteCampus reads the patron category upon authentication and 
only grants access to the resource to some selected categories.

ArteCampus uses CASv3 to authenticate against Bokeh (Bokeh gets a copy 
of koha users once a day).

Since Bokeh imports the patron category as a group, and CASv3 exports 
group information as an attribute upon authentication, ArteCampus can 
read this information, to check if a user can be granted access to a 
resource.

It is then possible for the librarians who manage ArteCampus to deny 
access to resource for certain koha categories.

This works with ArteCampus because they made some effort into 
integrating users attributes but I don't know if that would be easily 
reproducible with any other electronic resource provider, people would 
need to ask their provider if they have those kind of features, which 
may not be the case.


Maybe you could make something with koha permissions or a syspref so 
that the default category for self registered users is not able to login 
to the OPAC (nor the API...) until moved to a proper category by the 
librarians who validates the registration process?

Best,

Arthur

On 01/09/2022 07:39, Alex Buckley wrote:
>
> Hi Arthur,
>
> Thanks very much for your reply. Very interesting idea!
>
> Are the electronic resources that you hide with Bokeh the links in 
> biblio 856$u subfields?
>
> To give you some more context, one of the reasons this feature was 
> proposed was that as soon as patrons have a Koha userid and password 
> then they could authenticate (via Stunnel/SIP2) to electronic 
> platforms linked from the OpacNav HTML customisations on the OPAC home 
> page.
>
> Meaning if the OPAC has OPACPublic='Enable' then electronic resource 
> platform links in HTML customisations would be visible on the OPAC 
> home page and, therefore, accessible to all users regardless of their 
> patron category.
>
> Having some ability for libraries to moderate registrations, before 
> those users have a userid and password, would restrict whether they 
> could authenticate to these electronic platforms via Stunnel/SIP2.
>
> Thanks,
>
> Alex
>
>
> On 1/09/22 01:01, Arthur wrote:
>>
>> Hi Alex (&folks)
>>
>> What about the electronic ressources uses the Koha 
>> groups/patron_category to allow or deny access to the resource?
>>
>> Then if newly created patrons have a specific default category, then 
>> this category could be denied access to electronic resources.
>>
>> We've done this way for our frontend software (Bokeh) and it works 
>> quite well. Upon login, the patron category is received.
>>
>> Depending on the category, the user can see the links to electronic 
>> resource or not. Also the electronic resource server checks the 
>> category against Koha using CAS attributes.
>>
>> Cheers,
>>
>> Arthur
>>
>> On 31/08/2022 06:32, Alex Buckley wrote:
>>>
>>> Thanks for that Tomas, I appreciate it. I will add a separate 
>>> table(s) and will have a think about what you have noted.
>>>
>>> Kind regards,
>>>
>>> Alex
>>>
>>>
>>> On 31/08/22 14:35, Tomas Cohen Arazi wrote:
>>>> Please, use a separate table. And think of the request workflow 
>>>> handling in the db, the statuses (as enum), how it will be handled 
>>>> at library or library group level. Even if not implemented at this 
>>>> stage. Also, maybe you need more than one table, don't fear adding 
>>>> tables if they make sense and give us a cleaner implementation.
>>>>
>>>> Moderation should be traceable, etc.
>>>>
>>>> Thinking of API routes for the process usually clears the design 
>>>> issues as it points to the classes you will need.
>>>>
>>>> El lun, 29 ago 2022 19:46, Alex Buckley 
>>>> <alexbuckley at catalyst.net.nz> escribió:
>>>>
>>>>     Kia ora/Hello Koha community,
>>>>
>>>>     I am currently working on reviving bug 25090
>>>>     <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25090>
>>>>     ( Moderate OPAC self-registrations before a patron account is
>>>>     created ).
>>>>
>>>>     *New proposed functionality:*
>>>>
>>>>     Step 1: The library enables both the new
>>>>     'PatronSelfRegistrationModeration' syspref and the existing
>>>>     'OpacResetPassword'syspref.
>>>>
>>>>     Step 2: When a user submits an OPAC self-registration their
>>>>     Koha patron account is not created immediately - i.e. they
>>>>     cannot yet log into the OPAC.
>>>>
>>>>     Step 3: A pending registration link appears at the bottom of
>>>>     the staff client home page (like what's currently done with new
>>>>     purchase suggestions, or OPAC patron modification requests).
>>>>
>>>>     Step 4: Librarians can click on the link to go to a page to
>>>>     approve or decline the registration.
>>>>
>>>>     Step 4a: If approved the user is sent an email notice,
>>>>     containing their Koha username and an OPAC reset password link.
>>>>
>>>>     Step 4b: If declined the user is sent a different email notice.
>>>>
>>>>     *The rationale for adding this feature:*
>>>>     You can currently limit the circulation of self-registered
>>>>     patrons - by using the PatronSelfRegistrationDefaultCategory
>>>>     syspref and creating circulation rule(s) for that category.
>>>>
>>>>     However, users only need an OPAC login (without the ability to
>>>>     circulate) to access electronic content providers (integrated
>>>>     with Koha via STunnel/SIP2). Some electronic content providers
>>>>     charge libraries based on their usage. Meaning it might not be
>>>>     optimal having anyone from around the world self-registering
>>>>     for a library OPAC login and accessing electronic content from
>>>>     some providers, therefore, incurring extra costs for the library.
>>>>
>>>>     Bug 25090 was originally developed in the early days of the
>>>>     pandemic to ensure new self-registering OPAC users accessing
>>>>     3rd party databases were coming from acceptable locations i.e.
>>>>     they were members of the organisation the library is in.
>>>>
>>>>     More details can be found here:
>>>>     https://www.catalyst.net.nz/blog/mental-health-education-resource-library-now-offers-online-self-registration
>>>>
>>>>     *Questions I would like to hear your thoughts on please:*
>>>>
>>>>     Q1: Are you in favour of this as a new feature in Koha?
>>>>
>>>>     Q2: Would you prefer a new database table be added for
>>>>     self-registrations awaiting approval, or should I use the
>>>>     borrowers_modifications table - as is used by OPAC patron
>>>>     modification requests?
>>>>
>>>>     Q3: How would you envisage this self-registration moderation
>>>>     feature fitting in with the existing
>>>>     PatronSelfRegistrationVerifyByEmailand
>>>>     PatronSelfRegistrationDefaultCategory sysprefs?
>>>>
>>>>     Any thoughts much appreciated.
>>>>
>>>>     Kind regards,
>>>>
>>>>     Alex
>>>>
>>>>     _______________________________________________
>>>>     Koha-devel mailing list
>>>>     Koha-devel at 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/
>>>>
>>> -- 
>>> Alex Buckley
>>> Koha Developer | Implementation Lead
>>> Catalyst IT - Expert Open Source Solutions
>>>
>>> Catalyst.Net Ltd - a Catalyst IT group company
>>>
>>> CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.
>>> It may contain privileged, confidential or copyright information. If you are not
>>> the named recipient, any use, reliance upon, disclosure or copying of this email
>>> or its attachments is unauthorised. If you have received this email in error,
>>> please reply via email or call +64 4 499 2267.
>>>
>>> _______________________________________________
>>> Koha-devel mailing list
>>> Koha-devel at 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/
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at 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/
> -- 
> Alex Buckley
> Koha Developer | Implementation Lead
> Catalyst IT - Expert Open Source Solutions
>
> Catalyst.Net Ltd - a Catalyst IT group company
>
> CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.
> It may contain privileged, confidential or copyright information. If you are not
> the named recipient, any use, reliance upon, disclosure or copying of this email
> or its attachments is unauthorised. If you have received this email in error,
> please reply via email or call +64 4 499 2267.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220901/55a8870b/attachment-0001.htm>

From dcook at prosentient.com.au  Fri Sep  2 01:42:44 2022
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Fri, 2 Sep 2022 09:42:44 +1000
Subject: [Koha-devel] Enable libraries to moderate OPAC
 self-registrations
In-Reply-To: <84a5b948-29dd-599f-5f07-692d496f1b19@catalyst.net.nz>
References: <16588a0a-a8b9-e4a9-f2de-13d084785a4c@catalyst.net.nz>
 <CABZfb=U7XMt4d3Mf1Vh1Fgm_iuGboUYd62icxbZLn1jqEjfHBw@mail.gmail.com>
 <7d13ac6a-6fec-9526-a514-d1aece591f22@catalyst.net.nz>
 <a5a23b3b-e50e-ee63-79a0-5a9781baa158@biblibre.com>
 <84a5b948-29dd-599f-5f07-692d496f1b19@catalyst.net.nz>
Message-ID: <0f1001d8be5c$93c8d1f0$bb5a75d0$@prosentient.com.au>

You know one option would be to add a Restriction/Debarment to the user on self-registration (like we do locally) and then make sure that SIP doesn’t allow login for restricted patrons (I notice that is what we do locally as well). 

 

It wouldn’t meet all use cases, but it could work for yours. 

 

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: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Alex Buckley
Sent: Thursday, 1 September 2022 3:40 PM
To: Arthur <arthur.suzuki at biblibre.com>; koha-devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] Enable libraries to moderate OPAC self-registrations

 

Hi Arthur, 

Thanks very much for your reply. Very interesting idea!

Are the electronic resources that you hide with Bokeh the links in biblio 856$u subfields? 

To give you some more context, one of the reasons this feature was proposed was that as soon as patrons have a Koha userid and password then they could authenticate (via Stunnel/SIP2) to electronic platforms linked from the OpacNav HTML customisations on the OPAC home page.

Meaning if the OPAC has OPACPublic='Enable' then electronic resource platform links in HTML customisations would be visible on the OPAC home page and, therefore, accessible to all users regardless of their patron category.

Having some ability for libraries to moderate registrations, before those users have a userid and password, would restrict whether they could authenticate to these electronic platforms via Stunnel/SIP2.

Thanks,

Alex

 

On 1/09/22 01:01, Arthur wrote:

Hi Alex (&folks)

What about the electronic ressources uses the Koha groups/patron_category to allow or deny access to the resource?

Then if newly created patrons have a specific default category, then this category could be denied access to electronic resources.

We've done this way for our frontend software (Bokeh) and it works quite well. Upon login, the patron category is received.

Depending on the category, the user can see the links to electronic resource or not. Also the electronic resource server checks the category against Koha using CAS attributes.

Cheers,

Arthur

On 31/08/2022 06:32, Alex Buckley wrote:

Thanks for that Tomas, I appreciate it. I will add a separate table(s) and will have a think about what you have noted.

Kind regards,

Alex

 

On 31/08/22 14:35, Tomas Cohen Arazi wrote:

Please, use a separate table. And think of the request workflow handling in the db, the statuses (as enum), how it will be handled at library or library group level. Even if not implemented at this stage. Also, maybe you need more than one table, don't fear adding tables if they make sense and give us a cleaner implementation. 

 

Moderation should be traceable, etc.

 

Thinking of API routes for the process usually clears the design issues as it points to the classes you will need.

 

El lun, 29 ago 2022 19:46, Alex Buckley <alexbuckley at catalyst.net.nz <mailto:alexbuckley at catalyst.net.nz> > escribió:

Kia ora/Hello Koha community, 

I am currently working on reviving bug 25090 <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25090>  ( Moderate OPAC self-registrations before a patron account is created ).

New proposed functionality:

Step 1: The library enables both the new 'PatronSelfRegistrationModeration' syspref and the existing 'OpacResetPassword' syspref.



Step 2: When a user submits an OPAC self-registration their Koha patron account is not created immediately - i.e. they cannot yet log into the OPAC.



Step 3: A pending registration link appears at the bottom of the staff client home page (like what's currently done with new purchase suggestions, or OPAC patron modification requests). 



Step 4: Librarians can click on the link to go to a page to approve or decline the registration.

Step 4a: If approved the user is sent an email notice, containing their Koha username and an OPAC reset password link.



Step 4b: If declined the user is sent a different email notice.



The rationale for adding this feature:
You can currently limit the circulation of self-registered patrons - by using the PatronSelfRegistrationDefaultCategory syspref and creating circulation rule(s) for that category.



However, users only need an OPAC login (without the ability to circulate) to access electronic content providers (integrated with Koha via STunnel/SIP2). Some electronic content providers charge libraries based on their usage. Meaning it might not be optimal having anyone from around the world self-registering for a library OPAC login and accessing electronic content from some providers, therefore, incurring extra costs for the library.



Bug 25090 was originally developed in the early days of the pandemic to ensure new self-registering OPAC users accessing 3rd party databases were coming from acceptable locations i.e. they were members of the organisation the library is in.



More details can be found here: https://www.catalyst.net.nz/blog/mental-health-education-resource-library-now-offers-online-self-registration



Questions I would like to hear your thoughts on please: 

Q1: Are you in favour of this as a new feature in Koha?



Q2: Would you prefer a new database table be added for self-registrations awaiting approval, or should I use the borrowers_modifications table - as is used by OPAC patron modification requests?

Q3: How would you envisage this self-registration moderation feature fitting in with the existing  PatronSelfRegistrationVerifyByEmail and PatronSelfRegistrationDefaultCategory sysprefs?

Any thoughts much appreciated.

Kind regards,



Alex



_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at 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/

-- 
Alex Buckley
Koha Developer | Implementation Lead
Catalyst IT - Expert Open Source Solutions
 
Catalyst.Net Ltd - a Catalyst IT group company
 
CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.
It may contain privileged, confidential or copyright information. If you are not
the named recipient, any use, reliance upon, disclosure or copying of this email
or its attachments is unauthorised. If you have received this email in error,
please reply via email or call +64 4 499 2267.





_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at 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/





_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at 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/

-- 
Alex Buckley
Koha Developer | Implementation Lead
Catalyst IT - Expert Open Source Solutions
 
Catalyst.Net Ltd - a Catalyst IT group company
 
CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.
It may contain privileged, confidential or copyright information. If you are not
the named recipient, any use, reliance upon, disclosure or copying of this email
or its attachments is unauthorised. If you have received this email in error,
please reply via email or call +64 4 499 2267.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220902/ed6f2e66/attachment.htm>

From alexbuckley at catalyst.net.nz  Mon Sep  5 02:26:18 2022
From: alexbuckley at catalyst.net.nz (Alex Buckley)
Date: Mon, 5 Sep 2022 12:26:18 +1200
Subject: [Koha-devel] Enable libraries to moderate OPAC
 self-registrations
In-Reply-To: <0f1001d8be5c$93c8d1f0$bb5a75d0$@prosentient.com.au>
References: <16588a0a-a8b9-e4a9-f2de-13d084785a4c@catalyst.net.nz>
 <CABZfb=U7XMt4d3Mf1Vh1Fgm_iuGboUYd62icxbZLn1jqEjfHBw@mail.gmail.com>
 <7d13ac6a-6fec-9526-a514-d1aece591f22@catalyst.net.nz>
 <a5a23b3b-e50e-ee63-79a0-5a9781baa158@biblibre.com>
 <84a5b948-29dd-599f-5f07-692d496f1b19@catalyst.net.nz>
 <0f1001d8be5c$93c8d1f0$bb5a75d0$@prosentient.com.au>
Message-ID: <54a1fb34-e416-9b13-8a2f-e75cb6d8cb68@catalyst.net.nz>

Hi David,

Thanks for your response. I think what you outline would work for our
use case and would be a good first step to be upstreamed also.

I feel like adding the functionality of giving librarians the ability to
moderate self-registrations could still be a good end goal for Koha - so
that the self registration behaviour could be more consistent with OPAC
patron self edit request behaviour. 

Could you please let me know how have you locally configured SIP to not
allow login for restricted patrons?

Kind regards,

Alex


On 2/09/22 11:42, dcook at prosentient.com.au wrote:
>
> You know one option would be to add a Restriction/Debarment to the
> user on self-registration (like we do locally) and then make sure that
> SIP doesn’t allow login for restricted patrons (I notice that is what
> we do locally as well).
>
>  
>
> It wouldn’t meet all use cases, but it could work for yours.
>
>  
>
> 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:*Koha-devel <koha-devel-bounces at lists.koha-community.org> *On
> Behalf Of *Alex Buckley
> *Sent:* Thursday, 1 September 2022 3:40 PM
> *To:* Arthur <arthur.suzuki at biblibre.com>; koha-devel
> <koha-devel at lists.koha-community.org>
> *Subject:* Re: [Koha-devel] Enable libraries to moderate OPAC
> self-registrations
>
>  
>
> Hi Arthur,
>
> Thanks very much for your reply. Very interesting idea!
>
> Are the electronic resources that you hide with Bokeh the links in
> biblio 856$u subfields?
>
> To give you some more context, one of the reasons this feature was
> proposed was that as soon as patrons have a Koha userid and password
> then they could authenticate (via Stunnel/SIP2) to electronic
> platforms linked from the OpacNav HTML customisations on the OPAC home
> page.
>
> Meaning if the OPAC has OPACPublic='Enable' then electronic resource
> platform links in HTML customisations would be visible on the OPAC
> home page and, therefore, accessible to all users regardless of their
> patron category.
>
> Having some ability for libraries to moderate registrations, before
> those users have a userid and password, would restrict whether they
> could authenticate to these electronic platforms via Stunnel/SIP2.
>
> Thanks,
>
> Alex
>
>  
>
> On 1/09/22 01:01, Arthur wrote:
>
>     Hi Alex (&folks)
>
>     What about the electronic ressources uses the Koha
>     groups/patron_category to allow or deny access to the resource?
>
>     Then if newly created patrons have a specific default category,
>     then this category could be denied access to electronic resources.
>
>     We've done this way for our frontend software (Bokeh) and it works
>     quite well. Upon login, the patron category is received.
>
>     Depending on the category, the user can see the links to
>     electronic resource or not. Also the electronic resource server
>     checks the category against Koha using CAS attributes.
>
>     Cheers,
>
>     Arthur
>
>     On 31/08/2022 06:32, Alex Buckley wrote:
>
>         Thanks for that Tomas, I appreciate it. I will add a separate
>         table(s) and will have a think about what you have noted.
>
>         Kind regards,
>
>         Alex
>
>          
>
>         On 31/08/22 14:35, Tomas Cohen Arazi wrote:
>
>             Please, use a separate table. And think of the request
>             workflow handling in the db, the statuses (as enum), how
>             it will be handled at library or library group level. Even
>             if not implemented at this stage. Also, maybe you need
>             more than one table, don't fear adding tables if they make
>             sense and give us a cleaner implementation.
>
>              
>
>             Moderation should be traceable, etc.
>
>              
>
>             Thinking of API routes for the process usually clears the
>             design issues as it points to the classes you will need.
>
>              
>
>             El lun, 29 ago 2022 19:46, Alex Buckley
>             <alexbuckley at catalyst.net.nz> escribió:
>
>                 Kia ora/Hello Koha community,
>
>                 I am currently working on reviving bug 25090
>                 <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25090>
>                 ( Moderate OPAC self-registrations before a patron
>                 account is created ).
>
>                 *New proposed functionality:*
>
>                 Step 1: The library enables both the new
>                 'PatronSelfRegistrationModeration' syspref and the
>                 existing 'OpacResetPassword' syspref.
>
>                 Step 2: When a user submits an OPAC self-registration
>                 their Koha patron account is not created immediately -
>                 i.e. they cannot yet log into the OPAC.
>
>                 Step 3: A pending registration link appears at the
>                 bottom of the staff client home page (like what's
>                 currently done with new purchase suggestions, or OPAC
>                 patron modification requests).
>
>                 Step 4: Librarians can click on the link to go to a
>                 page to approve or decline the registration.
>
>                 Step 4a: If approved the user is sent an email notice,
>                 containing their Koha username and an OPAC reset
>                 password link.
>
>                 Step 4b: If declined the user is sent a different
>                 email notice.
>
>                 *The rationale for adding this feature:*
>                 You can currently limit the circulation of
>                 self-registered patrons - by using the
>                 PatronSelfRegistrationDefaultCategory syspref and
>                 creating circulation rule(s) for that category.
>
>                 However, users only need an OPAC login (without the
>                 ability to circulate) to access electronic content
>                 providers (integrated with Koha via STunnel/SIP2).
>                 Some electronic content providers charge libraries
>                 based on their usage. Meaning it might not be optimal
>                 having anyone from around the world self-registering
>                 for a library OPAC login and accessing electronic
>                 content from some providers, therefore, incurring
>                 extra costs for the library.
>
>                 Bug 25090 was originally developed in the early days
>                 of the pandemic to ensure new self-registering OPAC
>                 users accessing 3rd party databases were coming from
>                 acceptable locations i.e. they were members of the
>                 organisation the library is in.
>
>                 More details can be found here:
>                 https://www.catalyst.net.nz/blog/mental-health-education-resource-library-now-offers-online-self-registration
>
>                 *Questions I would like to hear your thoughts on please:*
>
>                 Q1: Are you in favour of this as a new feature in Koha?
>
>                 Q2: Would you prefer a new database table be added for
>                 self-registrations awaiting approval, or should I use
>                 the borrowers_modifications table - as is used by OPAC
>                 patron modification requests?
>
>                 Q3: How would you envisage this self-registration
>                 moderation feature fitting in with the existing 
>                 PatronSelfRegistrationVerifyByEmail and
>                 PatronSelfRegistrationDefaultCategory sysprefs?
>
>                 Any thoughts much appreciated.
>
>                 Kind regards,
>
>                 Alex
>
>                 _______________________________________________
>                 Koha-devel mailing list
>                 Koha-devel at 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/
>
>         -- 
>
>         Alex Buckley
>
>         Koha Developer | Implementation Lead
>
>         Catalyst IT - Expert Open Source Solutions
>
>          
>
>         Catalyst.Net Ltd - a Catalyst IT group company
>
>          
>
>         CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.
>
>         It may contain privileged, confidential or copyright information. If you are not
>
>         the named recipient, any use, reliance upon, disclosure or copying of this email
>
>         or its attachments is unauthorised. If you have received this email in error,
>
>         please reply via email or call +64 4 499 2267.
>
>
>
>         _______________________________________________
>
>         Koha-devel mailing list
>
>         Koha-devel at 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/
>
>
>
>     _______________________________________________
>
>     Koha-devel mailing list
>
>     Koha-devel at 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/
>
> -- 
> Alex Buckley
> Koha Developer | Implementation Lead
> Catalyst IT - Expert Open Source Solutions
>  
> Catalyst.Net Ltd - a Catalyst IT group company
>  
> CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.
> It may contain privileged, confidential or copyright information. If you are not
> the named recipient, any use, reliance upon, disclosure or copying of this email
> or its attachments is unauthorised. If you have received this email in error,
> please reply via email or call +64 4 499 2267.

-- 
Alex Buckley
Koha Developer | Implementation Lead
Catalyst IT - Expert Open Source Solutions

Catalyst.Net Ltd - a Catalyst IT group company

CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.
It may contain privileged, confidential or copyright information. If you are not
the named recipient, any use, reliance upon, disclosure or copying of this email
or its attachments is unauthorised. If you have received this email in error,
please reply via email or call +64 4 499 2267.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220905/1d44fe35/attachment-0001.htm>

From alexbuckley at catalyst.net.nz  Mon Sep  5 03:12:50 2022
From: alexbuckley at catalyst.net.nz (Alex Buckley)
Date: Mon, 5 Sep 2022 13:12:50 +1200
Subject: [Koha-devel] Enable libraries to moderate OPAC
 self-registrations
In-Reply-To: <4c4653eb-b360-9470-425e-9ed336c76a3e@biblibre.com>
References: <16588a0a-a8b9-e4a9-f2de-13d084785a4c@catalyst.net.nz>
 <CABZfb=U7XMt4d3Mf1Vh1Fgm_iuGboUYd62icxbZLn1jqEjfHBw@mail.gmail.com>
 <7d13ac6a-6fec-9526-a514-d1aece591f22@catalyst.net.nz>
 <a5a23b3b-e50e-ee63-79a0-5a9781baa158@biblibre.com>
 <84a5b948-29dd-599f-5f07-692d496f1b19@catalyst.net.nz>
 <4c4653eb-b360-9470-425e-9ed336c76a3e@biblibre.com>
Message-ID: <20d496d7-4b15-2156-ac35-e2b50718fabf@catalyst.net.nz>

Hi Arthur,

Thanks for your response! It's always interesting to hear other Koha
vendors' workflows.

I think a combination of what you outline and what David C suggested
would work.

When a new syspref is enabled then the default category of
self-registered users is restricted from logging in via SIP2. Therefore,
they can see and click on the links to electronic resources, but not
authenticate until a librarian has shifted them to a different patron
category. 

What I will do is write patches for this as the first step.

As I mentioned in the email response to David just now I still think
adding the ability for librarians to moderate patron accounts in a
similar way as is done for patron self-edit requests would be a useful
end goal, but upstreaming the above behavior would be a good first step
to build on.

Many thanks,

Alex


On 2/09/22 00:53, Arthur wrote:
>
> Hi Alex,
>
> In our case (Koha + Bokeh + ArteCampus), being able to authenticate
> against Koha doesn't mean someone would be granted access the resource
> (permissions are managed by ArteCampus).
>
> In our case, any koha user can authenticate and see the link to the
> resource, even non connected users can see the link.
>
> However, ArteCampus reads the patron category upon authentication and
> only grants access to the resource to some selected categories.
>
> ArteCampus uses CASv3 to authenticate against Bokeh (Bokeh gets a copy
> of koha users once a day).
>
> Since Bokeh imports the patron category as a group, and CASv3 exports
> group information as an attribute upon authentication, ArteCampus can
> read this information, to check if a user can be granted access to a
> resource.
>
> It is then possible for the librarians who manage ArteCampus to deny
> access to resource for certain koha categories.
>
> This works with ArteCampus because they made some effort into
> integrating users attributes but I don't know if that would be easily
> reproducible with any other electronic resource provider, people would
> need to ask their provider if they have those kind of features, which
> may not be the case.
>
>
> Maybe you could make something with koha permissions or a syspref so
> that the default category for self registered users is not able to
> login to the OPAC (nor the API...) until moved to a proper category by
> the librarians who validates the registration process?
>
> Best,
>
> Arthur
>
> On 01/09/2022 07:39, Alex Buckley wrote:
>>
>> Hi Arthur,
>>
>> Thanks very much for your reply. Very interesting idea!
>>
>> Are the electronic resources that you hide with Bokeh the links in
>> biblio 856$u subfields?
>>
>> To give you some more context, one of the reasons this feature was
>> proposed was that as soon as patrons have a Koha userid and password
>> then they could authenticate (via Stunnel/SIP2) to electronic
>> platforms linked from the OpacNav HTML customisations on the OPAC
>> home page.
>>
>> Meaning if the OPAC has OPACPublic='Enable' then electronic resource
>> platform links in HTML customisations would be visible on the OPAC
>> home page and, therefore, accessible to all users regardless of their
>> patron category.
>>
>> Having some ability for libraries to moderate registrations, before
>> those users have a userid and password, would restrict whether they
>> could authenticate to these electronic platforms via Stunnel/SIP2.
>>
>> Thanks,
>>
>> Alex
>>
>>
>> On 1/09/22 01:01, Arthur wrote:
>>>
>>> Hi Alex (&folks)
>>>
>>> What about the electronic ressources uses the Koha
>>> groups/patron_category to allow or deny access to the resource?
>>>
>>> Then if newly created patrons have a specific default category, then
>>> this category could be denied access to electronic resources.
>>>
>>> We've done this way for our frontend software (Bokeh) and it works
>>> quite well. Upon login, the patron category is received.
>>>
>>> Depending on the category, the user can see the links to electronic
>>> resource or not. Also the electronic resource server checks the
>>> category against Koha using CAS attributes.
>>>
>>> Cheers,
>>>
>>> Arthur
>>>
>>> On 31/08/2022 06:32, Alex Buckley wrote:
>>>>
>>>> Thanks for that Tomas, I appreciate it. I will add a separate
>>>> table(s) and will have a think about what you have noted.
>>>>
>>>> Kind regards,
>>>>
>>>> Alex
>>>>
>>>>
>>>> On 31/08/22 14:35, Tomas Cohen Arazi wrote:
>>>>> Please, use a separate table. And think of the request workflow
>>>>> handling in the db, the statuses (as enum), how it will be handled
>>>>> at library or library group level. Even if not implemented at this
>>>>> stage. Also, maybe you need more than one table, don't fear adding
>>>>> tables if they make sense and give us a cleaner implementation.
>>>>>
>>>>> Moderation should be traceable, etc.
>>>>>
>>>>> Thinking of API routes for the process usually clears the design
>>>>> issues as it points to the classes you will need.
>>>>>
>>>>> El lun, 29 ago 2022 19:46, Alex Buckley
>>>>> <alexbuckley at catalyst.net.nz> escribió:
>>>>>
>>>>>     Kia ora/Hello Koha community,
>>>>>
>>>>>     I am currently working on reviving bug 25090
>>>>>     <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25090>
>>>>>     ( Moderate OPAC self-registrations before a patron account is
>>>>>     created ).
>>>>>
>>>>>     *New proposed functionality:*
>>>>>
>>>>>     Step 1: The library enables both the new
>>>>>     'PatronSelfRegistrationModeration' syspref and the existing
>>>>>     'OpacResetPassword'syspref.
>>>>>
>>>>>     Step 2: When a user submits an OPAC self-registration their
>>>>>     Koha patron account is not created immediately - i.e. they
>>>>>     cannot yet log into the OPAC.
>>>>>
>>>>>     Step 3: A pending registration link appears at the bottom of
>>>>>     the staff client home page (like what's currently done with
>>>>>     new purchase suggestions, or OPAC patron modification requests).
>>>>>
>>>>>     Step 4: Librarians can click on the link to go to a page to
>>>>>     approve or decline the registration.
>>>>>
>>>>>     Step 4a: If approved the user is sent an email notice,
>>>>>     containing their Koha username and an OPAC reset password link.
>>>>>
>>>>>     Step 4b: If declined the user is sent a different email notice.
>>>>>
>>>>>     *The rationale for adding this feature:*
>>>>>     You can currently limit the circulation of self-registered
>>>>>     patrons - by using the PatronSelfRegistrationDefaultCategory
>>>>>     syspref and creating circulation rule(s) for that category.
>>>>>
>>>>>     However, users only need an OPAC login (without the ability to
>>>>>     circulate) to access electronic content providers (integrated
>>>>>     with Koha via STunnel/SIP2). Some electronic content providers
>>>>>     charge libraries based on their usage. Meaning it might not be
>>>>>     optimal having anyone from around the world self-registering
>>>>>     for a library OPAC login and accessing electronic content from
>>>>>     some providers, therefore, incurring extra costs for the library.
>>>>>
>>>>>     Bug 25090 was originally developed in the early days of the
>>>>>     pandemic to ensure new self-registering OPAC users accessing
>>>>>     3rd party databases were coming from acceptable locations i.e.
>>>>>     they were members of the organisation the library is in.
>>>>>
>>>>>     More details can be found here:
>>>>>     https://www.catalyst.net.nz/blog/mental-health-education-resource-library-now-offers-online-self-registration
>>>>>
>>>>>     *Questions I would like to hear your thoughts on please:*
>>>>>
>>>>>     Q1: Are you in favour of this as a new feature in Koha?
>>>>>
>>>>>     Q2: Would you prefer a new database table be added for
>>>>>     self-registrations awaiting approval, or should I use the
>>>>>     borrowers_modifications table - as is used by OPAC patron
>>>>>     modification requests?
>>>>>
>>>>>     Q3: How would you envisage this self-registration moderation
>>>>>     feature fitting in with the existing 
>>>>>     PatronSelfRegistrationVerifyByEmailand
>>>>>     PatronSelfRegistrationDefaultCategory sysprefs?
>>>>>
>>>>>     Any thoughts much appreciated.
>>>>>
>>>>>     Kind regards,
>>>>>
>>>>>     Alex
>>>>>
>>>>>     _______________________________________________
>>>>>     Koha-devel mailing list
>>>>>     Koha-devel at 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/
>>>>>
>>>> -- 
>>>> Alex Buckley
>>>> Koha Developer | Implementation Lead
>>>> Catalyst IT - Expert Open Source Solutions
>>>>
>>>> Catalyst.Net Ltd - a Catalyst IT group company
>>>>
>>>> CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.
>>>> It may contain privileged, confidential or copyright information. If you are not
>>>> the named recipient, any use, reliance upon, disclosure or copying of this email
>>>> or its attachments is unauthorised. If you have received this email in error,
>>>> please reply via email or call +64 4 499 2267.
>>>>
>>>> _______________________________________________
>>>> Koha-devel mailing list
>>>> Koha-devel at 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/
>>>
>>> _______________________________________________
>>> Koha-devel mailing list
>>> Koha-devel at 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/
>> -- 
>> Alex Buckley
>> Koha Developer | Implementation Lead
>> Catalyst IT - Expert Open Source Solutions
>>
>> Catalyst.Net Ltd - a Catalyst IT group company
>>
>> CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.
>> It may contain privileged, confidential or copyright information. If you are not
>> the named recipient, any use, reliance upon, disclosure or copying of this email
>> or its attachments is unauthorised. If you have received this email in error,
>> please reply via email or call +64 4 499 2267.

-- 
Alex Buckley
Koha Developer | Implementation Lead
Catalyst IT - Expert Open Source Solutions

Catalyst.Net Ltd - a Catalyst IT group company

CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.
It may contain privileged, confidential or copyright information. If you are not
the named recipient, any use, reliance upon, disclosure or copying of this email
or its attachments is unauthorised. If you have received this email in error,
please reply via email or call +64 4 499 2267.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220905/92eaa9d2/attachment-0001.htm>

From mik at adminkuhn.ch  Tue Sep  6 09:25:41 2022
From: mik at adminkuhn.ch (Michael Kuhn)
Date: Tue, 6 Sep 2022 09:25:41 +0200
Subject: [Koha-devel] [Koha] DBMS auto increment fix not working
In-Reply-To: <AM0PR0502MB374862CCAEAFF5C0CF4262CFCE799@AM0PR0502MB3748.eurprd05.prod.outlook.com>
References: <1ef4765c-2b40-8d39-ade8-469e3fe085d9@adminkuhn.ch>
 <AM0PR0502MB374862CCAEAFF5C0CF4262CFCE799@AM0PR0502MB3748.eurprd05.prod.outlook.com>
Message-ID: <393e75a8-fac7-5321-81b1-3a553d05513f@adminkuhn.ch>

Hi Marcel

Unfortunately it seems like the mailing list is not accepting my 
original answer to your e-mail (I tried twice). Instead after some days 
I received an e-mail with the subject "Undelivered Mail Returned to 
Sender", telling me

The mail system

<koha at lists.katipo.co.nz>: connect to lists.katipo.co.nz[202.70.130.220]:25:
     Connection refused

I don't even know if this e-mail is getting through. There's probably 
something wrong with the mailing list when not accepting answers.

Best wishes: Michael
-- 
Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
T 0041 (0)61 261 55 61 · E mik at adminkuhn.ch · W www.adminkuhn.ch



Am 30.08.22 um 13:17 schrieb Marcel de Rooy:
> Hi,
> 
> The fact that it will no longer happen under MariaDB 10.5.15 does not guarantee that you still suffer the consequences of older occurrences.
> The wiki promises a script but it never made it probably. But the easiest 'solution' is deleting the records in the deleted_* tables that have a corresponding id in the normal tables.
> After that verify that your autoincrement pointers on the normal tables are higher than the maximum id values in the deleted tables. If they would not be, you may bump into the issue again one day.
> 
> Marcel
> 
> ________________________________
> Van: Koha <koha-bounces at lists.katipo.co.nz> namens Michael Kuhn <mik at adminkuhn.ch>
> Verzonden: donderdag 25 augustus 2022 11:03
> Aan: Koha <koha at lists.katipo.co.nz>
> Onderwerp: [Koha] DBMS auto increment fix not working
> 
> Hi
> 
> In our library we are using Debian 11 with MariaDB 10.5.15 and Koha
> 21.05.14.
> 
> When deleting bibliographic records in the staff client, some deletions
> produce the message: "An error has occurred! Error 500 / This message
> may have been caused by any of the following reasons: etc." In such
> cases Koha menu "About Koha > System information" shows the message
> aubout data problems, saying
> 
>    Some of your tables have problems with their auto_increment values
> which may lead to data loss.
> 
>    You should not ignore this warning.
> 
>    The problem is that InnoDB does not keep auto_increment across SQL
> server restarts (it is only set in memory). So on server startup the
> auto_increment values are set to max(table.id)+1.
> 
>    To know how to avoid this problem see the related wiki page: DBMS auto
> increment fix
> 
> 
> According to
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.koha-community.org%2Fwiki%2FDBMS_auto_increment_fix&amp;data=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C5c1a779522df4601c58808da8678d0b4%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637970150719835805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=5BkXPF4yrrhvuLP1nFx66eQITkFCQPhoGPDtsdCDWso%3D&amp;reserved=0 the problem
> shouldn't appear with MariaDB 10.5.15 but as a trial we have implemented
> the solution described there and have restarted everything - still the
> problem persists.
> 
> In such cases file "plack-error.log" shows the following:
> 
>    {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Duplicate entry
> '6187-marcxml-MARC21' for key 'deletedbiblio_metadata_uniq_key' [for
> Statement "
>                   INSERT INTO deletedbiblio_metadata (biblionumber,
> format, `schema`, metadata)
>                   SELECT biblionumber, format, `schema`, metadata FROM
> biblio_metadata WHERE biblionumber=?
>               "] at /usr/share/koha/lib/C4/Biblio.pm line 2907
> 
> I suspect this behavior indeed looks like the original auto_increment
> problem described in bugs 18242, 18651, 18966, 19106 and 20271 but the
> reason may in fact not be the same since the described problem shouldn't
> appear at all in MariaDB 10.5.15.
> 
> Does anyone have an idea what is happening and how we can solve it?
> 
> Best wishes: Michael
> --
> Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
> Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
> T 0041 (0)61 261 55 61 · E mik at adminkuhn.ch · W https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.adminkuhn.ch%2F&amp;data=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C5c1a779522df4601c58808da8678d0b4%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637970150719835805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=fS0wgTtECweT98NfdwYV%2FV82IYhpm82iqLYuWP8war4%3D&amp;reserved=0
> _______________________________________________
> 
> Koha mailing list  https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkoha-community.org%2F&amp;data=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C5c1a779522df4601c58808da8678d0b4%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637970150719835805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=8d%2BiOpLG4oo49VF%2BwC9Y9hA7ZDJ6nUxcb2v7K1qdaxs%3D&amp;reserved=0
> Koha at lists.katipo.co.nz
> Unsubscribe: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.katipo.co.nz%2Fmailman%2Flistinfo%2Fkoha&amp;data=05%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C5c1a779522df4601c58808da8678d0b4%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637970150719835805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=jNLi6yPA%2FG5CLqcpf1nVBI4tnedT4a7zHdM4wWMpcXI%3D&amp;reserved=0
> _______________________________________________
> 
> Koha mailing list  http://koha-community.org
> Koha at lists.katipo.co.nz
> Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha



From M.de.Rooy at rijksmuseum.nl  Tue Sep  6 13:21:01 2022
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Tue, 6 Sep 2022 11:21:01 +0000
Subject: [Koha-devel] Regular Koha Mailing list down ?
Message-ID: <DB6PR0501MB25973D604A8249CEA0EB7553CE7E9@DB6PR0501MB2597.eurprd05.prod.outlook.com>

Hi CHris,

It seems that the mails to the regular Koha ML (katipo one) are not coming thru since September 1.
The archive also shows August entries.

Do you know how to resolve?

Thanks,
Marcel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220906/7faa0a50/attachment.htm>

From katrin.fischer.83 at web.de  Tue Sep  6 16:42:51 2022
From: katrin.fischer.83 at web.de (Katrin Fischer)
Date: Tue, 6 Sep 2022 16:42:51 +0200
Subject: [Koha-devel] Enable libraries to moderate OPAC
 self-registrations
In-Reply-To: <CABZfb=U7XMt4d3Mf1Vh1Fgm_iuGboUYd62icxbZLn1jqEjfHBw@mail.gmail.com>
References: <16588a0a-a8b9-e4a9-f2de-13d084785a4c@catalyst.net.nz>
 <CABZfb=U7XMt4d3Mf1Vh1Fgm_iuGboUYd62icxbZLn1jqEjfHBw@mail.gmail.com>
Message-ID: <9741b057-4026-b2bf-d7d1-95f96f12e084@web.de>

Hi all,

I think the feature would be useful. :)

I feel there has been some misunderstanding about the
borrower_modifications table. It doesn't require a valid borrowernumber
as the table is used for at least 2 purposes already:

* Patron data modification requests from the OPAC (borrowernumber of patron)

* Patron self registrations with required email verification
(borrowernumber = 0)

It's used as a temporary storage for patron data and I am not sure if a
separate table would makes sense as the table structure would probably
be really similar. We already need to keep 3 tables in sync when adding
columns: borrowers, deletedborrowers, borrower_modifications. We might
also want to think about how the data will move when email verification
is used in addition to moderation.

Hope this helps,

Katrin

On 31.08.22 04:35, Tomas Cohen Arazi wrote:
> Please, use a separate table. And think of the request workflow
> handling in the db, the statuses (as enum), how it will be handled at
> library or library group level. Even if not implemented at this stage.
> Also, maybe you need more than one table, don't fear adding tables if
> they make sense and give us a cleaner implementation.
>
> Moderation should be traceable, etc.
>
> Thinking of API routes for the process usually clears the design
> issues as it points to the classes you will need.
>
> El lun, 29 ago 2022 19:46, Alex Buckley <alexbuckley at catalyst.net.nz>
> escribió:
>
>     Kia ora/Hello Koha community,
>
>     I am currently working on reviving bug 25090
>     <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25090>
>     ( Moderate OPAC self-registrations before a patron account is
>     created ).
>
>     *New proposed functionality:*
>
>     Step 1: The library enables both the new
>     'PatronSelfRegistrationModeration' syspref and the existing
>     'OpacResetPassword'syspref.
>
>     Step 2: When a user submits an OPAC self-registration their Koha
>     patron account is not created immediately - i.e. they cannot yet
>     log into the OPAC.
>
>     Step 3: A pending registration link appears at the bottom of the
>     staff client home page (like what's currently done with new
>     purchase suggestions, or OPAC patron modification requests).
>
>     Step 4: Librarians can click on the link to go to a page to
>     approve or decline the registration.
>
>     Step 4a: If approved the user is sent an email notice, containing
>     their Koha username and an OPAC reset password link.
>
>     Step 4b: If declined the user is sent a different email notice.
>
>     *The rationale for adding this feature:*
>     You can currently limit the circulation of self-registered patrons
>     - by using the PatronSelfRegistrationDefaultCategory syspref and
>     creating circulation rule(s) for that category.
>
>     However, users only need an OPAC login (without the ability to
>     circulate) to access electronic content providers (integrated with
>     Koha via STunnel/SIP2). Some electronic content providers charge
>     libraries based on their usage. Meaning it might not be optimal
>     having anyone from around the world self-registering for a library
>     OPAC login and accessing electronic content from some providers,
>     therefore, incurring extra costs for the library.
>
>     Bug 25090 was originally developed in the early days of the
>     pandemic to ensure new self-registering OPAC users accessing 3rd
>     party databases were coming from acceptable locations i.e. they
>     were members of the organisation the library is in.
>
>     More details can be found here:
>     https://www.catalyst.net.nz/blog/mental-health-education-resource-library-now-offers-online-self-registration
>
>     *Questions I would like to hear your thoughts on please:*
>
>     Q1: Are you in favour of this as a new feature in Koha?
>
>     Q2: Would you prefer a new database table be added for
>     self-registrations awaiting approval, or should I use the
>     borrowers_modifications table - as is used by OPAC patron
>     modification requests?
>
>     Q3: How would you envisage this self-registration moderation
>     feature fitting in with the existing
>     PatronSelfRegistrationVerifyByEmailand
>     PatronSelfRegistrationDefaultCategory sysprefs?
>
>     Any thoughts much appreciated.
>
>     Kind regards,
>
>     Alex
>
>     _______________________________________________
>     Koha-devel mailing list
>     Koha-devel at 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/
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220906/2b379368/attachment-0001.htm>

From tomascohen at gmail.com  Tue Sep  6 17:04:08 2022
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Tue, 6 Sep 2022 08:04:08 -0700
Subject: [Koha-devel] Enable libraries to moderate OPAC
 self-registrations
In-Reply-To: <9741b057-4026-b2bf-d7d1-95f96f12e084@web.de>
References: <16588a0a-a8b9-e4a9-f2de-13d084785a4c@catalyst.net.nz>
 <CABZfb=U7XMt4d3Mf1Vh1Fgm_iuGboUYd62icxbZLn1jqEjfHBw@mail.gmail.com>
 <9741b057-4026-b2bf-d7d1-95f96f12e084@web.de>
Message-ID: <CABZfb=Vd9ux9ka2ZTTiHP=XFhj9jH-prqyxrMmyp-YHCE1_6Zg@mail.gmail.com>

I think we need to resurrect the idea of a patron import staging + import
step. This one being a particular use case.

El mar, 6 sept 2022 a las 7:43, Katrin Fischer (<katrin.fischer.83 at web.de>)
escribió:

> Hi all,
>
> I think the feature would be useful. :)
>
> I feel there has been some misunderstanding about the
> borrower_modifications table. It doesn't require a valid borrowernumber as
> the table is used for at least 2 purposes already:
>
> * Patron data modification requests from the OPAC (borrowernumber of
> patron)
>
> * Patron self registrations with required email verification
> (borrowernumber = 0)
>
> It's used as a temporary storage for patron data and I am not sure if a
> separate table would makes sense as the table structure would probably be
> really similar. We already need to keep 3 tables in sync when adding
> columns: borrowers, deletedborrowers, borrower_modifications. We might also
> want to think about how the data will move when email verification is used
> in addition to moderation.
>
> Hope this helps,
>
> Katrin
> On 31.08.22 04:35, Tomas Cohen Arazi wrote:
>
> Please, use a separate table. And think of the request workflow handling
> in the db, the statuses (as enum), how it will be handled at library or
> library group level. Even if not implemented at this stage. Also, maybe you
> need more than one table, don't fear adding tables if they make sense and
> give us a cleaner implementation.
>
> Moderation should be traceable, etc.
>
> Thinking of API routes for the process usually clears the design issues as
> it points to the classes you will need.
>
> El lun, 29 ago 2022 19:46, Alex Buckley <alexbuckley at catalyst.net.nz>
> escribió:
>
>> Kia ora/Hello Koha community,
>>
>> I am currently working on reviving bug 25090
>> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25090> ( Moderate
>> OPAC self-registrations before a patron account is created ).
>>
>> *New proposed functionality:*
>>
>> Step 1: The library enables both the new
>> 'PatronSelfRegistrationModeration' syspref and the existing
>> 'OpacResetPassword' syspref.
>>
>> Step 2: When a user submits an OPAC self-registration their Koha patron
>> account is not created immediately - i.e. they cannot yet log into the OPAC.
>>
>> Step 3: A pending registration link appears at the bottom of the staff
>> client home page (like what's currently done with new purchase suggestions,
>> or OPAC patron modification requests).
>>
>> Step 4: Librarians can click on the link to go to a page to approve or
>> decline the registration.
>>
>> Step 4a: If approved the user is sent an email notice, containing their
>> Koha username and an OPAC reset password link.
>>
>> Step 4b: If declined the user is sent a different email notice.
>>
>> *The rationale for adding this feature:*
>> You can currently limit the circulation of self-registered patrons - by
>> using the PatronSelfRegistrationDefaultCategory syspref and creating
>> circulation rule(s) for that category.
>>
>> However, users only need an OPAC login (without the ability to circulate)
>> to access electronic content providers (integrated with Koha via
>> STunnel/SIP2). Some electronic content providers charge libraries based on
>> their usage. Meaning it might not be optimal having anyone from around the
>> world self-registering for a library OPAC login and accessing electronic
>> content from some providers, therefore, incurring extra costs for the
>> library.
>>
>> Bug 25090 was originally developed in the early days of the pandemic to
>> ensure new self-registering OPAC users accessing 3rd party databases were
>> coming from acceptable locations i.e. they were members of the organisation
>> the library is in.
>>
>> More details can be found here:
>> https://www.catalyst.net.nz/blog/mental-health-education-resource-library-now-offers-online-self-registration
>> *Questions I would like to hear your thoughts on please:*
>>
>> Q1: Are you in favour of this as a new feature in Koha?
>>
>> Q2: Would you prefer a new database table be added for self-registrations
>> awaiting approval, or should I use the borrowers_modifications table - as
>> is used by OPAC patron modification requests?
>>
>> Q3: How would you envisage this self-registration moderation feature
>> fitting in with the existing  PatronSelfRegistrationVerifyByEmail and PatronSelfRegistrationDefaultCategory
>> sysprefs?
>>
>> Any thoughts much appreciated.
>>
>> Kind regards,
>>
>> Alex
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at 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/
>>
>
> _______________________________________________
> Koha-devel mailing listKoha-devel at lists.koha-community.orghttps://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/
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>


-- 
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/20220906/6949b93e/attachment.htm>

From Anke.Bruns at gwdg.de  Wed Sep  7 10:45:47 2022
From: Anke.Bruns at gwdg.de (Bruns, Anke)
Date: Wed, 7 Sep 2022 08:45:47 +0000
Subject: [Koha-devel] Regular Koha Mailing list down ?
In-Reply-To: <DB6PR0501MB25973D604A8249CEA0EB7553CE7E9@DB6PR0501MB2597.eurprd05.prod.outlook.com>
References: <DB6PR0501MB25973D604A8249CEA0EB7553CE7E9@DB6PR0501MB2597.eurprd05.prod.outlook.com>
Message-ID: <d6284eabd53745bc8d758cfca906ba6d@gwdg.de>

Hi,

thanks for this - I didn't get a mail through recently, and was wondering
why.

Best regards,
Anke

> -----Ursprüngliche Nachricht-----
> Von: Koha-devel <koha-devel-bounces at lists.koha-community.org> Im Auftrag
> von Marcel de Rooy
> Gesendet: Dienstag, 6. September 2022 13:21
> An: Chris Cormack <chris at bigballofwax.co.nz>; chrisc at catalyst.net.nz
> Cc: Koha-devel <koha-devel at lists.koha-community.org>
> Betreff: [Koha-devel] Regular Koha Mailing list down ?
> 
> Hi CHris,
> 
> It seems that the mails to the regular Koha ML (katipo one) are not coming
thru
> since September 1.
> The archive also shows August entries.
> 
> Do you know how to resolve?
> 
> Thanks,
> Marcel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7304 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220907/7140d7c4/attachment-0001.bin>

From dcook at prosentient.com.au  Fri Sep  9 01:07:15 2022
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Fri, 9 Sep 2022 09:07:15 +1000
Subject: [Koha-devel] Libraries using MARC 880 will need a fix...
Message-ID: <14ef01d8c3d7$bea810e0$3bf832a0$@prosentient.com.au>

Hi all,

 

A couple months ago I wrote a fix for "Bug 15187 - Adding 880 Fields to
index-list in order to Increase Search for ALL non-latin Scripts" for Zebra.


 

While it worked in terms of adding 880 to the indexing, it created an
unexpected problem with the search result display, since the MARC records in
the search results are fetched from Zebra and not MySQL. 

 

Yesterday, I raised "Bug 31532 - Zebra search results incorrect because of
Bug 15187". This uses pure Zebra configuration to use the same mechanism as
Bug 15187 but only at the indexing stage. Records retrieved from Zebra will
still be the original sent from Koha to Zebra. It's actually the original
solution I wrote for Bug 15187 before thinking there was an easier way. 

 

Fwiw, Elasticsearch indexes the 880 in its own way in the Koha code. 

 

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220909/fd2720db/attachment.htm>

From victor at tuxayo.net  Fri Sep  9 05:31:56 2022
From: victor at tuxayo.net (Victor Grousset/tuxayo)
Date: Fri, 9 Sep 2022 05:31:56 +0200
Subject: [Koha-devel] Forward this to librarians prone to contribute: Monday
 26th: patch testing session to help enhancements and bug fixes to be
 released
Message-ID: <462c3c85-da18-7946-22d3-3c530dc3d78a@tuxayo.net>

Hi :)

And also come, developers, admins, trainers, etc if you like a dedicated 
time with the community to test patches.

Let's meet at any moment in the following timeframe:
13h-19h UTC / 14h-20h UK/ 9h-15h US East/6h-12h US West
The place is https://visio.chapril.org/koha

Here is a resource about how to test patches using sandboxes:
https://wiki.koha-community.org/wiki/Sandboxes

Modalities:
The idea is to test patches to contribute to Koha. That's one of the 
**easiest and best way** to contribute to Koha. There is a huge need of 
testing to unblock patches and it would make a sizable difference in the 
pace of development of Koha if we reduce this bottleneck.
No need for particular skills, just basic Koha usage.
You can come an leave at any moment, even for a short time it's possible 
to get simple stuff moving forward.
We will use a VoIP call with chat tool to speak and eventually 
screenshare. It's possible to join without sound and only use chat. So 
if you are at the front desk and there are not much patrons you can 
still test patches ^^ And also it's easier if you aren't comfortable 
with oral english.

No need to have a local Koha instance. Just with a web browser we can 
use the sandboxes [1] to have temporary Kohas to test most of patches 
and do whatever we want without bad consequences.

Cheers,

[1] https://wiki.koha-community.org/wiki/Sandboxes

-- 
Victor Grousset/tuxayo

From philippe.blouin at inlibro.com  Fri Sep  9 17:41:17 2022
From: philippe.blouin at inlibro.com (Philippe Blouin)
Date: Fri, 9 Sep 2022 11:41:17 -0400
Subject: [Koha-devel] Elasticsearch not auto-updating after cataloguing
Message-ID: <07fa2219-34e0-0679-5381-ac534698b7a7@inlibro.com>

Hello kohaers!

Simply put: our production servers installation work very fine, each 
change into a record is immediately reindexed into ES.

BUT on laptop (ubuntu 20 or 22), the reindexing never occurs.  We have 
to call rebuild_elasticsearch.pl manually so the search finds anything.  
The configuration refers to a remote ES server (instead of localhost 
like the prod servers), but I don't see how that would make a difference 
since that works once rebuilt.

Any clue on what I'm missing would be greatly appreciated.

Best regards,

-- 
Philippe Blouin,
Directeur de la technologie

Tél.  : (833) 465-4276, poste 230
philippe.blouin at inLibro.com

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220909/6be75098/attachment.htm>

From tomascohen at gmail.com  Mon Sep 12 04:47:03 2022
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Sun, 11 Sep 2022 21:47:03 -0500
Subject: [Koha-devel] Elasticsearch not auto-updating after cataloguing
In-Reply-To: <07fa2219-34e0-0679-5381-ac534698b7a7@inlibro.com>
References: <07fa2219-34e0-0679-5381-ac534698b7a7@inlibro.com>
Message-ID: <CABZfb=VDSn6g=aFNG3QCENJyuEHOutYh3ooDk=+_jga3z4gNEg@mail.gmail.com>

Is koha-worker running?

El vie, 9 sept 2022 12:42, Philippe Blouin <philippe.blouin at inlibro.com>
escribió:

> Hello kohaers!
>
> Simply put: our production servers installation work very fine, each
> change into a record is immediately reindexed into ES.
>
> BUT on laptop (ubuntu 20 or 22), the reindexing never occurs.  We have to
> call rebuild_elasticsearch.pl manually so the search finds anything.  The
> configuration refers to a remote ES server (instead of localhost like the
> prod servers), but I don't see how that would make a difference since that
> works once rebuilt.
>
> Any clue on what I'm missing would be greatly appreciated.
>
> Best regards,
> --
> Philippe Blouin,
> Directeur de la technologie
>
> Tél.  : (833) 465-4276, poste 230
> philippe.blouin at inLibro.com
> inLibro | pour esprit libre | www.inLibro.com
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220911/d0833231/attachment.htm>

From alexbuckley at catalyst.net.nz  Mon Sep 12 10:20:40 2022
From: alexbuckley at catalyst.net.nz (Alex Buckley)
Date: Mon, 12 Sep 2022 20:20:40 +1200
Subject: [Koha-devel] Enable libraries to moderate OPAC
 self-registrations
In-Reply-To: <9741b057-4026-b2bf-d7d1-95f96f12e084@web.de>
References: <16588a0a-a8b9-e4a9-f2de-13d084785a4c@catalyst.net.nz>
 <CABZfb=U7XMt4d3Mf1Vh1Fgm_iuGboUYd62icxbZLn1jqEjfHBw@mail.gmail.com>
 <9741b057-4026-b2bf-d7d1-95f96f12e084@web.de>
Message-ID: <69125c6d-3531-f6e2-f9cf-e4fec00abfbf@catalyst.net.nz>

Hi Katrin,

Thanks so much for your response. Glad to hear you thought this would be
a useful feature :)

Thanks also for clarifying the use of the borrowernumber in the
borrower_modifications table.

I agree with Tomas in regards to having a new table(s) would make for a
cleaner implementation, but then you raise a good point about how a new
table could need to have a similar structure to borrowers,
deletedborrowers and borrowers_modifications.

Would it be considered problematic from a QA point of view to add a new
table that will have to be kept in sync every time new columns are added
to the borrowers table?

My thoughts regarding how data could flow when email verification is
used, in addition to moderation, were that after a patron registration
was approved it was only shifted to the borrowers table when the email
is verified - essentially keeping some of the current workflow. But
happy to do otherwise if you have anything in mind here?

Kind regards,

Alex


On 7/09/22 02:42, Katrin Fischer wrote:
>
> Hi all,
>
> I think the feature would be useful. :)
>
> I feel there has been some misunderstanding about the
> borrower_modifications table. It doesn't require a valid
> borrowernumber as the table is used for at least 2 purposes already:
>
> * Patron data modification requests from the OPAC (borrowernumber of
> patron)
>
> * Patron self registrations with required email verification
> (borrowernumber = 0)
>
> It's used as a temporary storage for patron data and I am not sure if
> a separate table would makes sense as the table structure would
> probably be really similar. We already need to keep 3 tables in sync
> when adding columns: borrowers, deletedborrowers,
> borrower_modifications. We might also want to think about how the data
> will move when email verification is used in addition to moderation.
>
> Hope this helps,
>
> Katrin
>
> On 31.08.22 04:35, Tomas Cohen Arazi wrote:
>> Please, use a separate table. And think of the request workflow
>> handling in the db, the statuses (as enum), how it will be handled at
>> library or library group level. Even if not implemented at this
>> stage. Also, maybe you need more than one table, don't fear adding
>> tables if they make sense and give us a cleaner implementation.
>>
>> Moderation should be traceable, etc.
>>
>> Thinking of API routes for the process usually clears the design
>> issues as it points to the classes you will need.
>>
>> El lun, 29 ago 2022 19:46, Alex Buckley <alexbuckley at catalyst.net.nz>
>> escribió:
>>
>>     Kia ora/Hello Koha community,
>>
>>     I am currently working on reviving bug 25090
>>     <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25090>
>>     ( Moderate OPAC self-registrations before a patron account is
>>     created ).
>>
>>     *New proposed functionality:*
>>
>>     Step 1: The library enables both the new
>>     'PatronSelfRegistrationModeration' syspref and the existing
>>     'OpacResetPassword'syspref.
>>
>>     Step 2: When a user submits an OPAC self-registration their Koha
>>     patron account is not created immediately - i.e. they cannot yet
>>     log into the OPAC.
>>
>>     Step 3: A pending registration link appears at the bottom of the
>>     staff client home page (like what's currently done with new
>>     purchase suggestions, or OPAC patron modification requests).
>>
>>     Step 4: Librarians can click on the link to go to a page to
>>     approve or decline the registration.
>>
>>     Step 4a: If approved the user is sent an email notice, containing
>>     their Koha username and an OPAC reset password link.
>>
>>     Step 4b: If declined the user is sent a different email notice.
>>
>>     *The rationale for adding this feature:*
>>     You can currently limit the circulation of self-registered
>>     patrons - by using the PatronSelfRegistrationDefaultCategory
>>     syspref and creating circulation rule(s) for that category.
>>
>>     However, users only need an OPAC login (without the ability to
>>     circulate) to access electronic content providers (integrated
>>     with Koha via STunnel/SIP2). Some electronic content providers
>>     charge libraries based on their usage. Meaning it might not be
>>     optimal having anyone from around the world self-registering for
>>     a library OPAC login and accessing electronic content from some
>>     providers, therefore, incurring extra costs for the library.
>>
>>     Bug 25090 was originally developed in the early days of the
>>     pandemic to ensure new self-registering OPAC users accessing 3rd
>>     party databases were coming from acceptable locations i.e. they
>>     were members of the organisation the library is in.
>>
>>     More details can be found here:
>>     https://www.catalyst.net.nz/blog/mental-health-education-resource-library-now-offers-online-self-registration
>>
>>     *Questions I would like to hear your thoughts on please:*
>>
>>     Q1: Are you in favour of this as a new feature in Koha?
>>
>>     Q2: Would you prefer a new database table be added for
>>     self-registrations awaiting approval, or should I use the
>>     borrowers_modifications table - as is used by OPAC patron
>>     modification requests?
>>
>>     Q3: How would you envisage this self-registration moderation
>>     feature fitting in with the existing 
>>     PatronSelfRegistrationVerifyByEmailand
>>     PatronSelfRegistrationDefaultCategory sysprefs?
>>
>>     Any thoughts much appreciated.
>>
>>     Kind regards,
>>
>>     Alex
>>
>>     _______________________________________________
>>     Koha-devel mailing list
>>     Koha-devel at 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/
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at 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/
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

-- 
Alex Buckley
Koha Developer | Implementation Lead
Catalyst IT - Expert Open Source Solutions

Catalyst.Net Ltd - a Catalyst IT group company

CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.
It may contain privileged, confidential or copyright information. If you are not
the named recipient, any use, reliance upon, disclosure or copying of this email
or its attachments is unauthorised. If you have received this email in error,
please reply via email or call +64 4 499 2267.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220912/a8f3ff9e/attachment-0001.htm>

From alexbuckley at catalyst.net.nz  Mon Sep 12 10:20:46 2022
From: alexbuckley at catalyst.net.nz (Alex Buckley)
Date: Mon, 12 Sep 2022 20:20:46 +1200
Subject: [Koha-devel] Enable libraries to moderate OPAC
 self-registrations
In-Reply-To: <CABZfb=Vd9ux9ka2ZTTiHP=XFhj9jH-prqyxrMmyp-YHCE1_6Zg@mail.gmail.com>
References: <16588a0a-a8b9-e4a9-f2de-13d084785a4c@catalyst.net.nz>
 <CABZfb=U7XMt4d3Mf1Vh1Fgm_iuGboUYd62icxbZLn1jqEjfHBw@mail.gmail.com>
 <9741b057-4026-b2bf-d7d1-95f96f12e084@web.de>
 <CABZfb=Vd9ux9ka2ZTTiHP=XFhj9jH-prqyxrMmyp-YHCE1_6Zg@mail.gmail.com>
Message-ID: <2e8f4a6c-9cac-cf21-1f4e-88af13bf2c95@catalyst.net.nz>

Good point Tomas. 

An unmoderated patron registration would be like a staged (but not
imported) patron record.

I see you created a bug report for that functionality on
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20916

Were you planning on working on that or is it available for others to
work on it?


On 7/09/22 03:04, Tomas Cohen Arazi wrote:
> I think we need to resurrect the idea of a patron import staging +
> import step. This one being a particular use case.
>
> El mar, 6 sept 2022 a las 7:43, Katrin Fischer
> (<katrin.fischer.83 at web.de>) escribió:
>
>     Hi all,
>
>     I think the feature would be useful. :)
>
>     I feel there has been some misunderstanding about the
>     borrower_modifications table. It doesn't require a valid
>     borrowernumber as the table is used for at least 2 purposes already:
>
>     * Patron data modification requests from the OPAC (borrowernumber
>     of patron)
>
>     * Patron self registrations with required email verification
>     (borrowernumber = 0)
>
>     It's used as a temporary storage for patron data and I am not sure
>     if a separate table would makes sense as the table structure would
>     probably be really similar. We already need to keep 3 tables in
>     sync when adding columns: borrowers, deletedborrowers,
>     borrower_modifications. We might also want to think about how the
>     data will move when email verification is used in addition to
>     moderation.
>
>     Hope this helps,
>
>     Katrin
>
>     On 31.08.22 04:35, Tomas Cohen Arazi wrote:
>>     Please, use a separate table. And think of the request workflow
>>     handling in the db, the statuses (as enum), how it will be
>>     handled at library or library group level. Even if not
>>     implemented at this stage. Also, maybe you need more than one
>>     table, don't fear adding tables if they make sense and give us a
>>     cleaner implementation.
>>
>>     Moderation should be traceable, etc.
>>
>>     Thinking of API routes for the process usually clears the design
>>     issues as it points to the classes you will need.
>>
>>     El lun, 29 ago 2022 19:46, Alex Buckley
>>     <alexbuckley at catalyst.net.nz> escribió:
>>
>>         Kia ora/Hello Koha community,
>>
>>         I am currently working on reviving bug 25090
>>         <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25090>
>>         ( Moderate OPAC self-registrations before a patron account is
>>         created ).
>>
>>         *New proposed functionality:*
>>
>>         Step 1: The library enables both the new
>>         'PatronSelfRegistrationModeration' syspref and the existing
>>         'OpacResetPassword'syspref.
>>
>>         Step 2: When a user submits an OPAC self-registration their
>>         Koha patron account is not created immediately - i.e. they
>>         cannot yet log into the OPAC.
>>
>>         Step 3: A pending registration link appears at the bottom of
>>         the staff client home page (like what's currently done with
>>         new purchase suggestions, or OPAC patron modification requests).
>>
>>         Step 4: Librarians can click on the link to go to a page to
>>         approve or decline the registration.
>>
>>         Step 4a: If approved the user is sent an email notice,
>>         containing their Koha username and an OPAC reset password link.
>>
>>         Step 4b: If declined the user is sent a different email notice.
>>
>>         *The rationale for adding this feature:*
>>         You can currently limit the circulation of self-registered
>>         patrons - by using the PatronSelfRegistrationDefaultCategory
>>         syspref and creating circulation rule(s) for that category.
>>
>>         However, users only need an OPAC login (without the ability
>>         to circulate) to access electronic content providers
>>         (integrated with Koha via STunnel/SIP2). Some electronic
>>         content providers charge libraries based on their usage.
>>         Meaning it might not be optimal having anyone from around the
>>         world self-registering for a library OPAC login and accessing
>>         electronic content from some providers, therefore, incurring
>>         extra costs for the library.
>>
>>         Bug 25090 was originally developed in the early days of the
>>         pandemic to ensure new self-registering OPAC users accessing
>>         3rd party databases were coming from acceptable locations
>>         i.e. they were members of the organisation the library is in.
>>
>>         More details can be found here:
>>         https://www.catalyst.net.nz/blog/mental-health-education-resource-library-now-offers-online-self-registration
>>
>>         *Questions I would like to hear your thoughts on please:*
>>
>>         Q1: Are you in favour of this as a new feature in Koha?
>>
>>         Q2: Would you prefer a new database table be added for
>>         self-registrations awaiting approval, or should I use the
>>         borrowers_modifications table - as is used by OPAC patron
>>         modification requests?
>>
>>         Q3: How would you envisage this self-registration moderation
>>         feature fitting in with the existing 
>>         PatronSelfRegistrationVerifyByEmailand
>>         PatronSelfRegistrationDefaultCategory sysprefs?
>>
>>         Any thoughts much appreciated.
>>
>>         Kind regards,
>>
>>         Alex
>>
>>         _______________________________________________
>>         Koha-devel mailing list
>>         Koha-devel at 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/
>>
>>
>>     _______________________________________________
>>     Koha-devel mailing list
>>     Koha-devel at 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/
>     _______________________________________________
>     Koha-devel mailing list
>     Koha-devel at 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/
>
>
>
> -- 
> Tomás Cohen Arazi
> Theke Solutions (http://theke.io)
> ✆ +54 9351 3513384
> GPG: B2F3C15F
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

-- 
Alex Buckley
Koha Developer | Implementation Lead
Catalyst IT - Expert Open Source Solutions

Catalyst.Net Ltd - a Catalyst IT group company

CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.
It may contain privileged, confidential or copyright information. If you are not
the named recipient, any use, reliance upon, disclosure or copying of this email
or its attachments is unauthorised. If you have received this email in error,
please reply via email or call +64 4 499 2267.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220912/1aed11c7/attachment-0001.htm>

From tomascohen at gmail.com  Mon Sep 12 14:34:50 2022
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Mon, 12 Sep 2022 09:34:50 -0300
Subject: [Koha-devel] Enable libraries to moderate OPAC
 self-registrations
In-Reply-To: <2e8f4a6c-9cac-cf21-1f4e-88af13bf2c95@catalyst.net.nz>
References: <16588a0a-a8b9-e4a9-f2de-13d084785a4c@catalyst.net.nz>
 <CABZfb=U7XMt4d3Mf1Vh1Fgm_iuGboUYd62icxbZLn1jqEjfHBw@mail.gmail.com>
 <9741b057-4026-b2bf-d7d1-95f96f12e084@web.de>
 <CABZfb=Vd9ux9ka2ZTTiHP=XFhj9jH-prqyxrMmyp-YHCE1_6Zg@mail.gmail.com>
 <2e8f4a6c-9cac-cf21-1f4e-88af13bf2c95@catalyst.net.nz>
Message-ID: <CABZfb=Xx4Yqin0=DVhu3+3g0ROoA_pSs-FWydKcx-7Bu2Bf36w@mail.gmail.com>

I'm not planning to work on that in a short term.

El lun, 12 sept 2022 a las 5:20, Alex Buckley (<alexbuckley at catalyst.net.nz>)
escribió:

> Good point Tomas.
>
> An unmoderated patron registration would be like a staged (but not
> imported) patron record.
>
> I see you created a bug report for that functionality on
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20916
>
> Were you planning on working on that or is it available for others to work
> on it?
>
>
> On 7/09/22 03:04, Tomas Cohen Arazi wrote:
>
> I think we need to resurrect the idea of a patron import staging + import
> step. This one being a particular use case.
>
> El mar, 6 sept 2022 a las 7:43, Katrin Fischer (<katrin.fischer.83 at web.de>)
> escribió:
>
>> Hi all,
>>
>> I think the feature would be useful. :)
>>
>> I feel there has been some misunderstanding about the
>> borrower_modifications table. It doesn't require a valid borrowernumber as
>> the table is used for at least 2 purposes already:
>>
>> * Patron data modification requests from the OPAC (borrowernumber of
>> patron)
>>
>> * Patron self registrations with required email verification
>> (borrowernumber = 0)
>>
>> It's used as a temporary storage for patron data and I am not sure if a
>> separate table would makes sense as the table structure would probably be
>> really similar. We already need to keep 3 tables in sync when adding
>> columns: borrowers, deletedborrowers, borrower_modifications. We might also
>> want to think about how the data will move when email verification is used
>> in addition to moderation.
>>
>> Hope this helps,
>>
>> Katrin
>> On 31.08.22 04:35, Tomas Cohen Arazi wrote:
>>
>> Please, use a separate table. And think of the request workflow handling
>> in the db, the statuses (as enum), how it will be handled at library or
>> library group level. Even if not implemented at this stage. Also, maybe you
>> need more than one table, don't fear adding tables if they make sense and
>> give us a cleaner implementation.
>>
>> Moderation should be traceable, etc.
>>
>> Thinking of API routes for the process usually clears the design issues
>> as it points to the classes you will need.
>>
>> El lun, 29 ago 2022 19:46, Alex Buckley <alexbuckley at catalyst.net.nz>
>> escribió:
>>
>>> Kia ora/Hello Koha community,
>>>
>>> I am currently working on reviving bug 25090
>>> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25090> ( Moderate
>>> OPAC self-registrations before a patron account is created ).
>>>
>>> *New proposed functionality:*
>>>
>>> Step 1: The library enables both the new
>>> 'PatronSelfRegistrationModeration' syspref and the existing
>>> 'OpacResetPassword' syspref.
>>>
>>> Step 2: When a user submits an OPAC self-registration their Koha patron
>>> account is not created immediately - i.e. they cannot yet log into the OPAC.
>>>
>>> Step 3: A pending registration link appears at the bottom of the staff
>>> client home page (like what's currently done with new purchase suggestions,
>>> or OPAC patron modification requests).
>>>
>>> Step 4: Librarians can click on the link to go to a page to approve or
>>> decline the registration.
>>>
>>> Step 4a: If approved the user is sent an email notice, containing their
>>> Koha username and an OPAC reset password link.
>>>
>>> Step 4b: If declined the user is sent a different email notice.
>>>
>>> *The rationale for adding this feature:*
>>> You can currently limit the circulation of self-registered patrons - by
>>> using the PatronSelfRegistrationDefaultCategory syspref and creating
>>> circulation rule(s) for that category.
>>>
>>> However, users only need an OPAC login (without the ability to
>>> circulate) to access electronic content providers (integrated with Koha via
>>> STunnel/SIP2). Some electronic content providers charge libraries based on
>>> their usage. Meaning it might not be optimal having anyone from around the
>>> world self-registering for a library OPAC login and accessing electronic
>>> content from some providers, therefore, incurring extra costs for the
>>> library.
>>>
>>> Bug 25090 was originally developed in the early days of the pandemic to
>>> ensure new self-registering OPAC users accessing 3rd party databases were
>>> coming from acceptable locations i.e. they were members of the organisation
>>> the library is in.
>>>
>>> More details can be found here:
>>> https://www.catalyst.net.nz/blog/mental-health-education-resource-library-now-offers-online-self-registration
>>> *Questions I would like to hear your thoughts on please:*
>>>
>>> Q1: Are you in favour of this as a new feature in Koha?
>>>
>>> Q2: Would you prefer a new database table be added for
>>> self-registrations awaiting approval, or should I use the
>>> borrowers_modifications table - as is used by OPAC patron modification
>>> requests?
>>>
>>> Q3: How would you envisage this self-registration moderation feature
>>> fitting in with the existing  PatronSelfRegistrationVerifyByEmail and PatronSelfRegistrationDefaultCategory
>>> sysprefs?
>>>
>>> Any thoughts much appreciated.
>>>
>>> Kind regards,
>>>
>>> Alex
>>> _______________________________________________
>>> Koha-devel mailing list
>>> Koha-devel at 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/
>>>
>>
>> _______________________________________________
>> Koha-devel mailing listKoha-devel at lists.koha-community.orghttps://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/
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at 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/
>>
>
>
> --
> Tomás Cohen Arazi
> Theke Solutions (http://theke.io)
> ✆ +54 9351 3513384
> GPG: B2F3C15F
>
> _______________________________________________
> Koha-devel mailing listKoha-devel at lists.koha-community.orghttps://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/
>
> --
> Alex Buckley
> Koha Developer | Implementation Lead
> Catalyst IT - Expert Open Source Solutions
>
> Catalyst.Net Ltd - a Catalyst IT group company
>
> CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.
> It may contain privileged, confidential or copyright information. If you are not
> the named recipient, any use, reliance upon, disclosure or copying of this email
> or its attachments is unauthorised. If you have received this email in error,
> please reply via email or call +64 4 499 2267.
>
>

-- 
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/20220912/0dfc49f5/attachment.htm>

From kohanews at gmail.com  Tue Sep 13 09:08:16 2022
From: kohanews at gmail.com (Koha Newsletter)
Date: Tue, 13 Sep 2022 09:08:16 +0200
Subject: [Koha-devel] Call for news - Newsletter September 2022
Message-ID: <CAEqgz_=GjR7tbn4oan0piL203ddfO_5ujJzx=MbfPvxiDdStJA@mail.gmail.com>

I'm collecting news for this month's newsletter. Send anything noteworthy to:

kohanews (at) gmail (dot) com

News criteria:
--------------

* News items can be of any length, images are fine.
* Please send your text in plain text or as simple HTML (no Word /
Google documents etc)
* Anything and everything Koha.
* Submit by the 26th of the month.

For events:
* Please include dates for past events. One month back is the cut-off.
* Announcements for future events with dates to be announced are fine,
e. g. Kohacon.

If you are working on an interesting project or development related to
Koha, please let me know and I'll include it in the development
section.

Thank you!

Michael Kuhn
Editor, Koha Community Newsletter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220913/59a5efeb/attachment-0001.htm>

From philippe.blouin at inlibro.com  Tue Sep 13 20:58:49 2022
From: philippe.blouin at inlibro.com (Philippe Blouin)
Date: Tue, 13 Sep 2022 14:58:49 -0400
Subject: [Koha-devel] Elasticsearch not auto-updating after cataloguing
In-Reply-To: <CABZfb=VDSn6g=aFNG3QCENJyuEHOutYh3ooDk=+_jga3z4gNEg@mail.gmail.com>
References: <07fa2219-34e0-0679-5381-ac534698b7a7@inlibro.com>
 <CABZfb=VDSn6g=aFNG3QCENJyuEHOutYh3ooDk=+_jga3z4gNEg@mail.gmail.com>
Message-ID: <ea590f7c-17c9-e7c1-359d-b25a0041a2c8@inlibro.com>

Hi!

Depends on the installation, but where background_jobs_worker.pl runs or 
not makes not difference in where the cataloguing->indexing path works.

It seems to always work when Koha runs on the same machine as ES, and 
not otherwise.

Still looking for possible clues.

Best regards,

Philippe Blouin,
Directeur de la technologie

Tél.  : (833) 465-4276, poste 230
philippe.blouin at inLibro.com

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
On 2022-09-11 22:47, Tomas Cohen Arazi wrote:
> Is koha-worker running?
>
> El vie, 9 sept 2022 12:42, Philippe Blouin 
> <philippe.blouin at inlibro.com> escribió:
>
>     Hello kohaers!
>
>     Simply put: our production servers installation work very fine,
>     each change into a record is immediately reindexed into ES.
>
>     BUT on laptop (ubuntu 20 or 22), the reindexing never occurs.  We
>     have to call rebuild_elasticsearch.pl
>     <http://rebuild_elasticsearch.pl> manually so the search finds
>     anything.  The configuration refers to a remote ES server (instead
>     of localhost like the prod servers), but I don't see how that
>     would make a difference since that works once rebuilt.
>
>     Any clue on what I'm missing would be greatly appreciated.
>
>     Best regards,
>
>     -- 
>     Philippe Blouin,
>     Directeur de la technologie
>
>     Tél.  : (833) 465-4276, poste 230
>     philippe.blouin at inLibro.com
>
>     inLibro | pour esprit libre | www.inLibro.com
>     <http://www.inLibro.com>
>     _______________________________________________
>     Koha-devel mailing list
>     Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220913/9b00ac59/attachment.htm>

From domm at plix.at  Tue Sep 13 22:33:32 2022
From: domm at plix.at (Thomas Klausner)
Date: Tue, 13 Sep 2022 22:33:32 +0200
Subject: [Koha-devel] Elasticsearch not auto-updating after cataloguing
In-Reply-To: <ea590f7c-17c9-e7c1-359d-b25a0041a2c8@inlibro.com>
References: <07fa2219-34e0-0679-5381-ac534698b7a7@inlibro.com>
 <CABZfb=VDSn6g=aFNG3QCENJyuEHOutYh3ooDk=+_jga3z4gNEg@mail.gmail.com>
 <ea590f7c-17c9-e7c1-359d-b25a0041a2c8@inlibro.com>
Message-ID: <20220913203332.GM490306@plix.at>

Hi!

On Tue, Sep 13, 2022 at 02:58:49PM -0400, Philippe Blouin wrote:
 
> Depends on the installation, but where background_jobs_worker.pl runs or not
> makes not difference in where the cataloguing->indexing path works.
> 
> It seems to always work when Koha runs on the same machine as ES, and not
> otherwise.

Is the remote ES exposed via https? Maybe you have slightly different 
Perls or Mozilla::CA installation? Any errors in the logs?

Which Koha Verion are you running? Are you sure both latpop and server 
run the same version?

In the source code there is a param 'skip_record_index', which will 
prevent the immediate indexing after an edit (if I've skimmed the code 
correctly). Maybe that is set? Though I don't know when it would be set 
(by whom..)

Greetings,
domm

-- 
#!/usr/bin/perl                             https://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

From dcook at prosentient.com.au  Wed Sep 14 08:42:55 2022
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Wed, 14 Sep 2022 16:42:55 +1000
Subject: [Koha-devel] Handling normalized phone number data
Message-ID: <19c201d8c805$48f950c0$daebf240$@prosentient.com.au>

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220914/cc5f2cca/attachment.htm>

From alexbuckley at catalyst.net.nz  Wed Sep 14 23:20:43 2022
From: alexbuckley at catalyst.net.nz (Alex Buckley)
Date: Thu, 15 Sep 2022 09:20:43 +1200
Subject: [Koha-devel] Enable libraries to moderate OPAC
 self-registrations
In-Reply-To: <CABZfb=Xx4Yqin0=DVhu3+3g0ROoA_pSs-FWydKcx-7Bu2Bf36w@mail.gmail.com>
References: <16588a0a-a8b9-e4a9-f2de-13d084785a4c@catalyst.net.nz>
 <CABZfb=U7XMt4d3Mf1Vh1Fgm_iuGboUYd62icxbZLn1jqEjfHBw@mail.gmail.com>
 <9741b057-4026-b2bf-d7d1-95f96f12e084@web.de>
 <CABZfb=Vd9ux9ka2ZTTiHP=XFhj9jH-prqyxrMmyp-YHCE1_6Zg@mail.gmail.com>
 <2e8f4a6c-9cac-cf21-1f4e-88af13bf2c95@catalyst.net.nz>
 <CABZfb=Xx4Yqin0=DVhu3+3g0ROoA_pSs-FWydKcx-7Bu2Bf36w@mail.gmail.com>
Message-ID: <f5e94340-ab01-5a22-95f3-16de5aa6c4c3@catalyst.net.nz>

Thanks Tomas!

On 13/09/22 00:34, Tomas Cohen Arazi wrote:
> I'm not planning to work on that in a short term.
>
> El lun, 12 sept 2022 a las 5:20, Alex Buckley
> (<alexbuckley at catalyst.net.nz>) escribió:
>
>     Good point Tomas. 
>
>     An unmoderated patron registration would be like a staged (but not
>     imported) patron record.
>
>     I see you created a bug report for that functionality on
>     https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20916
>
>     Were you planning on working on that or is it available for others
>     to work on it?
>
>
>     On 7/09/22 03:04, Tomas Cohen Arazi wrote:
>>     I think we need to resurrect the idea of a patron import
>>     staging + import step. This one being a particular use case.
>>
>>     El mar, 6 sept 2022 a las 7:43, Katrin Fischer
>>     (<katrin.fischer.83 at web.de>) escribió:
>>
>>         Hi all,
>>
>>         I think the feature would be useful. :)
>>
>>         I feel there has been some misunderstanding about the
>>         borrower_modifications table. It doesn't require a valid
>>         borrowernumber as the table is used for at least 2 purposes
>>         already:
>>
>>         * Patron data modification requests from the OPAC
>>         (borrowernumber of patron)
>>
>>         * Patron self registrations with required email verification
>>         (borrowernumber = 0)
>>
>>         It's used as a temporary storage for patron data and I am not
>>         sure if a separate table would makes sense as the table
>>         structure would probably be really similar. We already need
>>         to keep 3 tables in sync when adding columns: borrowers,
>>         deletedborrowers, borrower_modifications. We might also want
>>         to think about how the data will move when email verification
>>         is used in addition to moderation.
>>
>>         Hope this helps,
>>
>>         Katrin
>>
>>         On 31.08.22 04:35, Tomas Cohen Arazi wrote:
>>>         Please, use a separate table. And think of the request
>>>         workflow handling in the db, the statuses (as enum), how it
>>>         will be handled at library or library group level. Even if
>>>         not implemented at this stage. Also, maybe you need more
>>>         than one table, don't fear adding tables if they make sense
>>>         and give us a cleaner implementation.
>>>
>>>         Moderation should be traceable, etc.
>>>
>>>         Thinking of API routes for the process usually clears the
>>>         design issues as it points to the classes you will need.
>>>
>>>         El lun, 29 ago 2022 19:46, Alex Buckley
>>>         <alexbuckley at catalyst.net.nz> escribió:
>>>
>>>             Kia ora/Hello Koha community,
>>>
>>>             I am currently working on reviving bug 25090
>>>             <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25090>
>>>             ( Moderate OPAC self-registrations before a patron
>>>             account is created ).
>>>
>>>             *New proposed functionality:*
>>>
>>>             Step 1: The library enables both the new
>>>             'PatronSelfRegistrationModeration' syspref and the
>>>             existing 'OpacResetPassword'syspref.
>>>
>>>             Step 2: When a user submits an OPAC self-registration
>>>             their Koha patron account is not created immediately -
>>>             i.e. they cannot yet log into the OPAC.
>>>
>>>             Step 3: A pending registration link appears at the
>>>             bottom of the staff client home page (like what's
>>>             currently done with new purchase suggestions, or OPAC
>>>             patron modification requests).
>>>
>>>             Step 4: Librarians can click on the link to go to a page
>>>             to approve or decline the registration.
>>>
>>>             Step 4a: If approved the user is sent an email notice,
>>>             containing their Koha username and an OPAC reset
>>>             password link.
>>>
>>>             Step 4b: If declined the user is sent a different email
>>>             notice.
>>>
>>>             *The rationale for adding this feature:*
>>>             You can currently limit the circulation of
>>>             self-registered patrons - by using the
>>>             PatronSelfRegistrationDefaultCategory syspref and
>>>             creating circulation rule(s) for that category.
>>>
>>>             However, users only need an OPAC login (without the
>>>             ability to circulate) to access electronic content
>>>             providers (integrated with Koha via STunnel/SIP2). Some
>>>             electronic content providers charge libraries based on
>>>             their usage. Meaning it might not be optimal having
>>>             anyone from around the world self-registering for a
>>>             library OPAC login and accessing electronic content from
>>>             some providers, therefore, incurring extra costs for the
>>>             library.
>>>
>>>             Bug 25090 was originally developed in the early days of
>>>             the pandemic to ensure new self-registering OPAC users
>>>             accessing 3rd party databases were coming from
>>>             acceptable locations i.e. they were members of the
>>>             organisation the library is in.
>>>
>>>             More details can be found here:
>>>             https://www.catalyst.net.nz/blog/mental-health-education-resource-library-now-offers-online-self-registration
>>>
>>>             *Questions I would like to hear your thoughts on please:*
>>>
>>>             Q1: Are you in favour of this as a new feature in Koha?
>>>
>>>             Q2: Would you prefer a new database table be added for
>>>             self-registrations awaiting approval, or should I use
>>>             the borrowers_modifications table - as is used by OPAC
>>>             patron modification requests?
>>>
>>>             Q3: How would you envisage this self-registration
>>>             moderation feature fitting in with the existing 
>>>             PatronSelfRegistrationVerifyByEmailand
>>>             PatronSelfRegistrationDefaultCategory sysprefs?
>>>
>>>             Any thoughts much appreciated.
>>>
>>>             Kind regards,
>>>
>>>             Alex
>>>
>>>             _______________________________________________
>>>             Koha-devel mailing list
>>>             Koha-devel at 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/
>>>
>>>
>>>         _______________________________________________
>>>         Koha-devel mailing list
>>>         Koha-devel at 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/
>>         _______________________________________________
>>         Koha-devel mailing list
>>         Koha-devel at 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/
>>
>>
>>
>>     -- 
>>     Tomás Cohen Arazi
>>     Theke Solutions (http://theke.io)
>>     ✆ +54 9351 3513384
>>     GPG: B2F3C15F
>>
>>     _______________________________________________
>>     Koha-devel mailing list
>>     Koha-devel at 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/
>
>     -- 
>     Alex Buckley
>     Koha Developer | Implementation Lead
>     Catalyst IT - Expert Open Source Solutions
>
>     Catalyst.Net Ltd - a Catalyst IT group company
>
>     CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.
>     It may contain privileged, confidential or copyright information. If you are not
>     the named recipient, any use, reliance upon, disclosure or copying of this email
>     or its attachments is unauthorised. If you have received this email in error,
>     please reply via email or call +64 4 499 2267.
>
>
>
> -- 
> Tomás Cohen Arazi
> Theke Solutions (http://theke.io)
> ✆ +54 9351 3513384
> GPG: B2F3C15F

-- 
Alex Buckley
Koha Developer | Implementation Lead
Catalyst IT - Expert Open Source Solutions

Catalyst.Net Ltd - a Catalyst IT group company

CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.
It may contain privileged, confidential or copyright information. If you are not
the named recipient, any use, reliance upon, disclosure or copying of this email
or its attachments is unauthorised. If you have received this email in error,
please reply via email or call +64 4 499 2267.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220915/fc77d296/attachment-0001.htm>

From dcook at prosentient.com.au  Thu Sep 15 02:31:34 2022
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Thu, 15 Sep 2022 10:31:34 +1000
Subject: [Koha-devel] Handling normalized phone number data
In-Reply-To: <CAHGWiG6R9MVrU_sA70cZp8ds5TROoPU23vjcFw6Z7OB_QAqg4w@mail.gmail.com>
References: <19c201d8c805$48f950c0$daebf240$@prosentient.com.au>
 <CAHGWiG6R9MVrU_sA70cZp8ds5TROoPU23vjcFw6Z7OB_QAqg4w@mail.gmail.com>
Message-ID: <1a8901d8c89a$8f722190$ae5664b0$@prosentient.com.au>

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 at bywatersolutions.com> 
Sent: Wednesday, 14 September 2022 8:26 PM
To: dcook at prosentient.com.au
Cc: koha-devel <koha-devel at lists.koha-community.org>; Tomas Cohen Arazi <tomascohen at theke.io>; Martin Renvoize <martin.renvoize at 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 at prosentient.com.au <mailto:dcook at 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 at bywatersolutions.com> kyle at 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.htm>

From dcook at prosentient.com.au  Thu Sep 15 02:36:46 2022
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Thu, 15 Sep 2022 10:36:46 +1000
Subject: [Koha-devel] Handling normalized phone number data
In-Reply-To: <CABZfb=V7i-8xFb+2bjJuwpPEyTegB0ak-kUw1KKzAqz1uPfXcg@mail.gmail.com>
References: <19c201d8c805$48f950c0$daebf240$@prosentient.com.au>
 <CABZfb=V7i-8xFb+2bjJuwpPEyTegB0ak-kUw1KKzAqz1uPfXcg@mail.gmail.com>
Message-ID: <1a8e01d8c89b$4464c350$cd2e49f0$@prosentient.com.au>

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 at theke.io> 
Sent: Wednesday, 14 September 2022 11:10 PM
To: dcook at prosentient.com.au
Cc: koha-devel <koha-devel at lists.koha-community.org>; Kyle Hall <kyle at bywatersolutions.com>; Martin Renvoize <martin.renvoize at 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 at prosentient.com.au <mailto:dcook at 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-0001.htm>

From dcook at prosentient.com.au  Thu Sep 15 05:23:11 2022
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Thu, 15 Sep 2022 13:23:11 +1000
Subject: [Koha-devel] Handling normalized phone number data
In-Reply-To: <CABZfb=Uz+3jjiuQXWkxFZGh+DBkzvPEwsghtvtZFyWLSA7=Bwg@mail.gmail.com>
References: <19c201d8c805$48f950c0$daebf240$@prosentient.com.au>
 <CABZfb=V7i-8xFb+2bjJuwpPEyTegB0ak-kUw1KKzAqz1uPfXcg@mail.gmail.com>
 <1a8e01d8c89b$4464c350$cd2e49f0$@prosentient.com.au>
 <CABZfb=Uz+3jjiuQXWkxFZGh+DBkzvPEwsghtvtZFyWLSA7=Bwg@mail.gmail.com>
Message-ID: <1aff01d8c8b2$8fc69640$af53c2c0$@prosentient.com.au>

So you’d add it to the client side, eh…

 

I looked through “koha-tmpl/intranet-tmpl/prog/en/includes/patron-search.inc” and “koha-tmpl/intranet-tmpl/prog/js/datatables.js”, and found the DataTables integration with the REST API to be a bit… obscure. But now I see what you mean about adding an embed option via the kohaTable constructor. 

 

Although like Kyle was saying. Adding a phone number table wouldn’t solve this problem (unless we had a normalized phone number column).

 

That said, we wouldn’t need to normalize the phone number data, if we could use use SQL functions on the left hand side of a comparison: https://metacpan.org/dist/DBIx-Class/view/lib/DBIx/Class/Manual/Cookbook.pod#Using-SQL-functions-on-the-left-hand-side-of-a-comparison

 

It’s doable from a DBIC level but I don’t see how we can do it with the DataTables + REST API integration since it requires Perl-specific syntax that JSON can’t handle. Handing DBIC-like syntax to the REST API makes this really hard. 

 

The only thing I can think to do is to rewrite the query after it hits the REST API. 

 

I’ll be writing about that again shortly…

 

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 at theke.io> 
Sent: Thursday, 15 September 2022 11:06 AM
To: David Cook <dcook at prosentient.com.au>
Cc: koha-devel <koha-devel at lists.koha-community.org>; Kyle Hall <kyle at bywatersolutions.com>; Martin Renvoize <martin.renvoize at ptfs-europe.com>
Subject: Re: Handling normalized phone number data

 

For the REST API you would just add an embed option. Correct.

 

El mié, 14 sept 2022 21:37, <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> > escribió:

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 at theke.io <mailto:tomascohen at theke.io> > 
Sent: Wednesday, 14 September 2022 11:10 PM
To: dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> 
Cc: koha-devel <koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> >; Kyle Hall <kyle at bywatersolutions.com <mailto:kyle at bywatersolutions.com> >; Martin Renvoize <martin.renvoize at ptfs-europe.com <mailto:martin.renvoize at 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 at prosentient.com.au <mailto:dcook at 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/6a5ab28b/attachment.htm>

From dcook at prosentient.com.au  Thu Sep 15 06:32:42 2022
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Thu, 15 Sep 2022 14:32:42 +1000
Subject: [Koha-devel] Handling normalized phone number data
References: <19c201d8c805$48f950c0$daebf240$@prosentient.com.au>
 <CABZfb=V7i-8xFb+2bjJuwpPEyTegB0ak-kUw1KKzAqz1uPfXcg@mail.gmail.com>
 <1a8e01d8c89b$4464c350$cd2e49f0$@prosentient.com.au>
 <CABZfb=Uz+3jjiuQXWkxFZGh+DBkzvPEwsghtvtZFyWLSA7=Bwg@mail.gmail.com> 
Message-ID: <1b1001d8c8bc$41dbf290$c593d7b0$@prosentient.com.au>

At the moment, the only solution I can think of is to rewrite the DBIC query after it hits the REST API. I’ve figured out 3 ways to do it:

 

Current:

{"me.phone"=>{"like"=>"%020404123456%"}}

 

Option 1:

{"me.phone"=>{"in"=> \["SELECT phone FROM borrowers WHERE regexp_replace(phone,?,?) LIKE ?","[^0-9]","",$query->{'like'}]}

 

Option 2:

\["regexp_replace(me.phone,?,?) LIKE ?","[^0-9]","","%12345678901%"]

 

Option 3:

Delete {"me.phone"=>{"like"=>"%020404123456%"}}

Inject the following into the WHERE via the $attributes: \["regexp_replace(me.phone,?,?) LIKE ?","[^0-9]","","%12345678901%"]

 

On a database of over 100,000 patrons, Option 1 takes 3 seconds to return while Option 2 takes .2 seconds to return. Option 3 is a bit harder to test but should be the .2 seconds too.

 

The problem with Option 2 is that it nukes the original hashref, so if that hashref contains other keys for an OR query, they’d be lost. 

 

I was leaning towards Option 1 until I figured out Option 3.

 

Forutnately, DataTables sends a particular HTTP header, so I’m able to do the re-writing just for DataTables requests to the API.

 

I’ll be posting the patch to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23817 shortly.

 

Even if the community doesn’t go this way, I might use it locally anyway going forward. I’ve started rolling out a similar method for older Kohas because of the number of libraries flagging phone number searching as a problem. 

 

One way or another it’s a problem that needs to be solved…

 

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: dcook at prosentient.com.au <dcook at prosentient.com.au> 
Sent: Thursday, 15 September 2022 1:23 PM
To: 'Tomas Cohen Arazi' <tomascohen at theke.io>
Cc: 'koha-devel' <koha-devel at lists.koha-community.org>; 'Kyle Hall' <kyle at bywatersolutions.com>; 'Martin Renvoize' <martin.renvoize at ptfs-europe.com>
Subject: RE: Handling normalized phone number data

 

So you’d add it to the client side, eh…

 

I looked through “koha-tmpl/intranet-tmpl/prog/en/includes/patron-search.inc” and “koha-tmpl/intranet-tmpl/prog/js/datatables.js”, and found the DataTables integration with the REST API to be a bit… obscure. But now I see what you mean about adding an embed option via the kohaTable constructor. 

 

Although like Kyle was saying. Adding a phone number table wouldn’t solve this problem (unless we had a normalized phone number column).

 

That said, we wouldn’t need to normalize the phone number data, if we could use use SQL functions on the left hand side of a comparison: https://metacpan.org/dist/DBIx-Class/view/lib/DBIx/Class/Manual/Cookbook.pod#Using-SQL-functions-on-the-left-hand-side-of-a-comparison

 

It’s doable from a DBIC level but I don’t see how we can do it with the DataTables + REST API integration since it requires Perl-specific syntax that JSON can’t handle. Handing DBIC-like syntax to the REST API makes this really hard. 

 

The only thing I can think to do is to rewrite the query after it hits the REST API. 

 

I’ll be writing about that again shortly…

 

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 at theke.io <mailto:tomascohen at theke.io> > 
Sent: Thursday, 15 September 2022 11:06 AM
To: David Cook <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> >
Cc: koha-devel <koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> >; Kyle Hall <kyle at bywatersolutions.com <mailto:kyle at bywatersolutions.com> >; Martin Renvoize <martin.renvoize at ptfs-europe.com <mailto:martin.renvoize at ptfs-europe.com> >
Subject: Re: Handling normalized phone number data

 

For the REST API you would just add an embed option. Correct.

 

El mié, 14 sept 2022 21:37, <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> > escribió:

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 at theke.io <mailto:tomascohen at theke.io> > 
Sent: Wednesday, 14 September 2022 11:10 PM
To: dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> 
Cc: koha-devel <koha-devel at lists.koha-community.org>; Kyle Hall <kyle at bywatersolutions.com <mailto:kyle at bywatersolutions.com> >; Martin Renvoize <martin.renvoize at ptfs-europe.com <mailto:martin.renvoize at 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 at prosentient.com.au <mailto:dcook at 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/02edc252/attachment-0001.htm>

From mtj at kohaaloha.com  Thu Sep 15 11:48:02 2022
From: mtj at kohaaloha.com (Mason James)
Date: Thu, 15 Sep 2022 21:48:02 +1200
Subject: [Koha-devel] A guide for testing Koha's REST API
Message-ID: <96350436-830a-73a8-985f-c6e1814c6895@kohaaloha.com>

hi folks

i've made a guide here...

  https://wiki.koha-community.org/wiki/REST_API_Debug



From tomascohen at gmail.com  Thu Sep 15 13:30:47 2022
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Thu, 15 Sep 2022 08:30:47 -0300
Subject: [Koha-devel] A guide for testing Koha's REST API
In-Reply-To: <96350436-830a-73a8-985f-c6e1814c6895@kohaaloha.com>
References: <96350436-830a-73a8-985f-c6e1814c6895@kohaaloha.com>
Message-ID: <CABZfb=WftvqdfoXtdsUjjXLXTQ35nBm2Y7JSKLwLuwHZnfgU=A@mail.gmail.com>

Thank you!!

El jue, 15 sept 2022 6:48, Mason James <mtj at kohaaloha.com> escribió:

> hi folks
>
> i've made a guide here...
>
>   https://wiki.koha-community.org/wiki/REST_API_Debug
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220915/13a96608/attachment.htm>

From dcook at prosentient.com.au  Fri Sep 16 02:34:14 2022
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Fri, 16 Sep 2022 10:34:14 +1000
Subject: [Koha-devel] Handling normalized phone number data
In-Reply-To: <CABZfb=UGs_B7KDW0PXuzUckFQ4EK88YnDgp5GCCiO0Sn7cDxVg@mail.gmail.com>
References: <19c201d8c805$48f950c0$daebf240$@prosentient.com.au>
 <CABZfb=V7i-8xFb+2bjJuwpPEyTegB0ak-kUw1KKzAqz1uPfXcg@mail.gmail.com>
 <1a8e01d8c89b$4464c350$cd2e49f0$@prosentient.com.au>
 <CABZfb=Uz+3jjiuQXWkxFZGh+DBkzvPEwsghtvtZFyWLSA7=Bwg@mail.gmail.com>
 <1b1001d8c8bc$41dbf290$c593d7b0$@prosentient.com.au>
 <CABZfb=UGs_B7KDW0PXuzUckFQ4EK88YnDgp5GCCiO0Sn7cDxVg@mail.gmail.com>
Message-ID: <1bd801d8c964$1b4d1a20$51e74e60$@prosentient.com.au>

I think that there could be merit in having the separate table, although that would require changes to a number of different patron touch points. I don’t know how it would work with the “Import patrons” or “Batch patron modification” or “Batch patron deletion and anonymization” tools (among others). We’d also need to modify patron entry, modification, and self-registration.

 

I was thinking about your example, and I wasn’t sure how DBIC works with a 1 to Many relationship, so I came up with this example after consulting the wiki:

curl -u koha:koha --request GET 'http://127.0.0.1:8081/api/v1/patrons/51' --header "x-koha-embed: extended_attributes" 

 

I gave the patron multiple extended attributes and it did a fantastic job of including the extended attributes as objects in a list in the JSON output. Awesome! I think that could work really well with phones. (Having flags for “primary” and “sms” could be good in that table.)

 

My only hesitation would be with the time/energy that it would take to refactor Koha completely to use a separate phones table on my own :/. 

 

If it were a team effort, I’d be willing to help create and execute a plan though. 

 

It could also become a blueprint for how to denormalize other data in the borrowers table (like email and address). 

 

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 at theke.io> 
Sent: Thursday, 15 September 2022 9:59 PM
To: dcook at prosentient.com.au
Cc: koha-devel <koha-devel at lists.koha-community.org>; Kyle Hall <kyle at bywatersolutions.com>; Martin Renvoize <martin.renvoize at ptfs-europe.com>
Subject: Re: Handling normalized phone number data

 

I insist you should think longer term, and add a separate table. That way you will end up with a simpler (and more performant) query as well:

 

GET /patrons

x-koha-embed: phones

x-koha-query: {"phones.normalized":{"-like":"123%"}}

 

 

 

El jue, 15 sept 2022 a las 1:33, <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> > escribió:

At the moment, the only solution I can think of is to rewrite the DBIC query after it hits the REST API. I’ve figured out 3 ways to do it:

 

Current:

{"me.phone"=>{"like"=>"%020404123456%"}}

 

Option 1:

{"me.phone"=>{"in"=> \["SELECT phone FROM borrowers WHERE regexp_replace(phone,?,?) LIKE ?","[^0-9]","",$query->{'like'}]}

 

Option 2:

\["regexp_replace(me.phone,?,?) LIKE ?","[^0-9]","","%12345678901%"]

 

Option 3:

Delete {"me.phone"=>{"like"=>"%020404123456%"}}

Inject the following into the WHERE via the $attributes: \["regexp_replace(me.phone,?,?) LIKE ?","[^0-9]","","%12345678901%"]

 

On a database of over 100,000 patrons, Option 1 takes 3 seconds to return while Option 2 takes .2 seconds to return. Option 3 is a bit harder to test but should be the .2 seconds too.

 

The problem with Option 2 is that it nukes the original hashref, so if that hashref contains other keys for an OR query, they’d be lost. 

 

I was leaning towards Option 1 until I figured out Option 3.

 

Forutnately, DataTables sends a particular HTTP header, so I’m able to do the re-writing just for DataTables requests to the API.

 

I’ll be posting the patch to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23817 shortly.

 

Even if the community doesn’t go this way, I might use it locally anyway going forward. I’ve started rolling out a similar method for older Kohas because of the number of libraries flagging phone number searching as a problem. 

 

One way or another it’s a problem that needs to be solved…

 

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: dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>  <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> > 
Sent: Thursday, 15 September 2022 1:23 PM
To: 'Tomas Cohen Arazi' <tomascohen at theke.io <mailto:tomascohen at theke.io> >
Cc: 'koha-devel' <koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> >; 'Kyle Hall' <kyle at bywatersolutions.com <mailto:kyle at bywatersolutions.com> >; 'Martin Renvoize' <martin.renvoize at ptfs-europe.com <mailto:martin.renvoize at ptfs-europe.com> >
Subject: RE: Handling normalized phone number data

 

So you’d add it to the client side, eh…

 

I looked through “koha-tmpl/intranet-tmpl/prog/en/includes/patron-search.inc” and “koha-tmpl/intranet-tmpl/prog/js/datatables.js”, and found the DataTables integration with the REST API to be a bit… obscure. But now I see what you mean about adding an embed option via the kohaTable constructor. 

 

Although like Kyle was saying. Adding a phone number table wouldn’t solve this problem (unless we had a normalized phone number column).

 

That said, we wouldn’t need to normalize the phone number data, if we could use use SQL functions on the left hand side of a comparison: https://metacpan.org/dist/DBIx-Class/view/lib/DBIx/Class/Manual/Cookbook.pod#Using-SQL-functions-on-the-left-hand-side-of-a-comparison

 

It’s doable from a DBIC level but I don’t see how we can do it with the DataTables + REST API integration since it requires Perl-specific syntax that JSON can’t handle. Handing DBIC-like syntax to the REST API makes this really hard. 

 

The only thing I can think to do is to rewrite the query after it hits the REST API. 

 

I’ll be writing about that again shortly…

 

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 at theke.io <mailto:tomascohen at theke.io> > 
Sent: Thursday, 15 September 2022 11:06 AM
To: David Cook <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> >
Cc: koha-devel <koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> >; Kyle Hall <kyle at bywatersolutions.com <mailto:kyle at bywatersolutions.com> >; Martin Renvoize <martin.renvoize at ptfs-europe.com <mailto:martin.renvoize at ptfs-europe.com> >
Subject: Re: Handling normalized phone number data

 

For the REST API you would just add an embed option. Correct.

 

El mié, 14 sept 2022 21:37, <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> > escribió:

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 at theke.io <mailto:tomascohen at theke.io> > 
Sent: Wednesday, 14 September 2022 11:10 PM
To: dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> 
Cc: koha-devel <koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> >; Kyle Hall <kyle at bywatersolutions.com <mailto:kyle at bywatersolutions.com> >; Martin Renvoize <martin.renvoize at ptfs-europe.com <mailto:martin.renvoize at 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 at prosentient.com.au <mailto:dcook at 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




 

-- 

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/20220916/ef2db4e4/attachment-0001.htm>

From philippe.blouin at inlibro.com  Fri Sep 16 22:01:02 2022
From: philippe.blouin at inlibro.com (Philippe Blouin)
Date: Fri, 16 Sep 2022 16:01:02 -0400
Subject: [Koha-devel] Elasticsearch not auto-updating after cataloguing
In-Reply-To: <20220913203332.GM490306@plix.at>
References: <07fa2219-34e0-0679-5381-ac534698b7a7@inlibro.com>
 <CABZfb=VDSn6g=aFNG3QCENJyuEHOutYh3ooDk=+_jga3z4gNEg@mail.gmail.com>
 <ea590f7c-17c9-e7c1-359d-b25a0041a2c8@inlibro.com>
 <20220913203332.GM490306@plix.at>
Message-ID: <d4356a29-e744-a85e-effc-7c43e3e8d9ae@inlibro.com>

Hello Thomas,

I followed your tip the last few days.  At this point I've spotted which 
commit between 21 and 22 moved the reindexing to BackgroundJobs, and 
when set up correctly (the worker), it does reindex indeed.

But if rabbitmq runs, then it fails.   The background_jobs service gets 
the clue to look for job X: if connecte to MQ, it goes to the database 
with a ->find()... and gets nothing.  If MQ is not running, it goes to 
the database with a ->search() and process the jobs there with success.

*sigh*

So it is not a matter of Ubuntu version or remote vs local, but of a 
combination of Koha version, worker and rabbitmq.

NOW, if I put a "sleep 2" in background_jobs_worker.pl, just before the 
->find(), then it works.

Like if the Queue is faster than the Database ??!?!  Seems to me nothing 
is put onto the queue, especially not an ID, without the database entry 
being completed.


I have a feeling I'm deep into a rabbit (mq) hole, and I'm not seeing 
straight.


Thanks a lot,


Philippe Blouin,
Directeur de la technologie

Tél.  : (833) 465-4276, poste 230
philippe.blouin at inLibro.com

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
On 2022-09-13 16:33, Thomas Klausner wrote:
> Hi!
>
> On Tue, Sep 13, 2022 at 02:58:49PM -0400, Philippe Blouin wrote:
>   
>> Depends on the installation, but where background_jobs_worker.pl runs or not
>> makes not difference in where the cataloguing->indexing path works.
>>
>> It seems to always work when Koha runs on the same machine as ES, and not
>> otherwise.
> Is the remote ES exposed via https? Maybe you have slightly different
> Perls orMozilla::CA  installation? Any errors in the logs?
>
> Which Koha Verion are you running? Are you sure both latpop and server
> run the same version?
>
> In the source code there is a param 'skip_record_index', which will
> prevent the immediate indexing after an edit (if I've skimmed the code
> correctly). Maybe that is set? Though I don't know when it would be set
> (by whom..)
>
> Greetings,
> domm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220916/b9c705eb/attachment.htm>

From mtj at kohaaloha.com  Thu Sep 22 13:43:01 2022
From: mtj at kohaaloha.com (Mason James)
Date: Thu, 22 Sep 2022 23:43:01 +1200
Subject: [Koha-devel] Koha support for Debian 9 ends
Message-ID: <3698a550-1520-4d8b-fe2c-d998c26b8322@kohaaloha.com>

kia ora community,

debian ended support for debian 9 (stretch) on June 30, 2022

  https://wiki.debian.org/LTS
  https://www.debian.org/releases/stretch/


so, we recommend you upgrade any debian 9 Koha systems to debian 10 or 11

cheers, Mason

From mail at davidschmidt.at  Thu Sep 29 18:47:04 2022
From: mail at davidschmidt.at (David Schmidt)
Date: Thu, 29 Sep 2022 18:47:04 +0200
Subject: [Koha-devel] koha-create with remote mariadb server
Message-ID: <91bfd605-2f68-4ac6-91bd-962bd7c4064c@app.fastmail.com>

im trying to create a koha instance configured for a remote mariadb server

https://wiki.koha-community.org/wiki/Debian#Create_a_Koha_instance

> remove /etc/mysql/koha-common.cnf
> create a new file in its place containing the connection
                  information for the server, in the form of a my.cnf file.

what does that mean? the only my.cnf file that I can find on the system is /etc/mysql/my.cnf and that doesnt look right


$ koha-create --dbhost 172.23.0.3 --database kohadb --request-db koha-demo
$ vim koha-demo-db-request.txt
$ koha-create --dbhost 172.23.0.3 --database kohadb --populate-db koha-demo
Koha instance is empty, no staff user created.

after that I still see the autogenerated password in /etc/koha/sites/koha-demo/koha-conf.xml and the mariadb database is empty

after reading the koha-create source i have a feeling this --request-db/--populate-db stuff cant possibly work. --populate-db is trying to get the db passwort using getinstancemysqluser() but that function is a wrapper around xmlstarlet and i was just told by `koha-create --request-db` to write the new db password into this txt file.
 
I will update the wiki after I figured this out

cheers
david
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220929/5e5d6adc/attachment.htm>

From mik at adminkuhn.ch  Thu Sep 29 21:50:58 2022
From: mik at adminkuhn.ch (Michael Kuhn)
Date: Thu, 29 Sep 2022 21:50:58 +0200
Subject: [Koha-devel] Critical error on Koha website
Message-ID: <99fda852-8eec-43f8-be5d-d9d524ddd5cb@adminkuhn.ch>

Hi

When I'm trying to preview or release the current Koha newsletter I'm 
getting the following message:

There has been a critical error on this website.

I'm also getting this message when I try to access older newsletters, 
for example

* https://koha-community.org/koha-community-newsletter-april-2022/
* https://koha-community.org/koha-community-newsletter-august-2022/

Can someone with the necessary rights and knowledge please remove this 
problem?

Best wishes: Michael
-- 
Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
T 0041 (0)61 261 55 61 · E mik at adminkuhn.ch · W www.adminkuhn.ch

From kohanews at gmail.com  Fri Sep 30 00:59:22 2022
From: kohanews at gmail.com (Koha Newsletter)
Date: Fri, 30 Sep 2022 00:59:22 +0200
Subject: [Koha-devel] Koha Community Newsletter: September 2022
Message-ID: <CAEqgz_=u9gTXYh0bqaKJHOTqUFuYXeG5rBoF__rGV8raObwaUw@mail.gmail.com>

The Koha Community Newsletter for September 2022 is here:

https://koha-community.org/koha-community-newsletter-september-2022/

Many thanks to everyone who submitted articles and news to this newsletter!

Please feel free to email me with any corrections or suggestions.
--
Michael Kuhn
Editor, Koha Community Newsletter


PS. Unfortunately the Wordpress template for the Koha Community website has
considerably changed since the last newsletter (and not in a way that I
would prefer). This is not only affecting all previous newsletters since
2010 but also previous release notes etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220930/ca1b03ce/attachment.htm>

From domm at plix.at  Fri Sep 30 13:50:27 2022
From: domm at plix.at (Thomas Klausner)
Date: Fri, 30 Sep 2022 13:50:27 +0200
Subject: [Koha-devel] Bug 31654 - Hide non-public libraries from
 MastheadLibraryPulldown
Message-ID: <20220930115027.GB1853016@plix.at>

Hi!

I've just submitted a patch implementing Bug 31654 - Hide non-public libraries from MastheadLibraryPulldown

It's quite simple (two lines in two files), and the sponsor 
(Steiermärkische Landesbibliothek) would be happy if the fix makes it 
into 22.11. So if there is anything I can do to make that happen, please 
advise :-)

Greetings,
domm

-- 
#!/usr/bin/perl                             https://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

From domm at plix.at  Fri Sep 30 14:19:13 2022
From: domm at plix.at (Thomas Klausner)
Date: Fri, 30 Sep 2022 14:19:13 +0200
Subject: [Koha-devel] Merging authority records can corrupt data
Message-ID: <20220930121913.GC1853016@plix.at>

Hi!

It seems that merging authorities with lots of linked biblios can lead 
to data corruption (at least in 21.05):

The merging of the auth record itself seems to work, but the linking of 
the biblios from old to new auth record happens inside a normal 
synchrone web request. If this requests times out (because there might 
be a lot of biblio records to relink), some of the biblios still point 
to the old auth, which is already deleted. (At least this seems to be 
happening, based on the complaints we got from librarians)

I guess the only fix is to handle authority merging via background jobs 
/ job queue.

Is this a known bug? I couldn't find anything about that in bugzilla?
If yes, is there a timeframe when it will be fixed?
If no, I will create a bug (though reproducing it will need some weird 
fixtures in the DB..).

In any case, the Steiermärkische Landesbibliothek is keen to get this 
working, so I could give fixing it a try. But this will need some 
discussion, I assume? As I suppose this will be a bit more work than a 
single-line fix in a template, I'd like to have some backing by other 
Koha-devs, that this behaviour is indeed a bug, and that using 
background jobs is the correct way to fix it.

Greetings,
domm

-- 
#!/usr/bin/perl                             https://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

From mail at davidschmidt.at  Fri Sep 30 15:46:09 2022
From: mail at davidschmidt.at (David Schmidt)
Date: Fri, 30 Sep 2022 15:46:09 +0200
Subject: [Koha-devel] koha-create with remote mariadb server
In-Reply-To: <91bfd605-2f68-4ac6-91bd-962bd7c4064c@app.fastmail.com>
References: <91bfd605-2f68-4ac6-91bd-962bd7c4064c@app.fastmail.com>
Message-ID: <a989a3bf-7e99-4c94-a4ea-31acbda91067@app.fastmail.com>

with the help from koha irc and lots of try&error&code-reading I figured some things out

### on your database server:

apt update && apt install -y mariadb-server
sed -i -e 's/^bind-address\s*=\s*127\.0\.0\.1$/bind-address = */' /etc/mysql/mariadb.conf.d/50-server.cnf
/etc/init.d/mariadb restart
mysql -e "CREATE DATABASE koha_demo;"
mysql -e "CREATE USER 'koha_demo'@'%' IDENTIFIED BY 'kohadbpw';"
mysql -e "GRANT ALL PRIVILEGES on koha_demo.* TO koha_demo;"
mysql -e "FLUSH PRIVILEGES;"

### on your koha server
apt update && apt install -y wget gnupg
wget -q -O- https://debian.koha-community.org/koha/gpg.asc | apt-key add -
echo 'deb http://debian.koha-community.org/koha 22.05 main' | tee /etc/apt/sources.list.d/koha.list
apt update
apt install koha-common -y

a2enmod rewrite
a2enmod cgi
service apache2 restart

mv /etc/mysql/koha-common.cnf /etc/mysql/koha-common.cnf.bak
echo "[client]
host = mariadb
user = koha_demo
password = kohadbpw" > /etc/mysql/koha-common.cnf

sed -i -e 's/^DOMAIN="\.myDNSname\.org"$/DOMAIN=".koha-support.eu"/' /etc/koha/koha-sites.conf
sed -i -e 's/^OPACSUFFIX=""$/OPACSUFFIX="-opac"/' /etc/koha/koha-sites.conf

#instance:username:password:dbname:dbhost
echo "koha-demo:koha_demo:kohadbpw:koha_demo:mariadb" > koha_db_passwdfile.txt

koha-create --passwdfile=koha_db_passwdfile.txt --use-db koha-demo

On Thu, 29 Sep 2022, at 6:47 PM, David Schmidt wrote:
> im trying to create a koha instance configured for a remote mariadb server
> 
> https://wiki.koha-community.org/wiki/Debian#Create_a_Koha_instance
> 
> > remove /etc/mysql/koha-common.cnf
> > create a new file in its place containing the connection
>                   information for the server, in the form of a my.cnf file.
> 
> what does that mean? the only my.cnf file that I can find on the system is /etc/mysql/my.cnf and that doesnt look right
> 
> 
> $ koha-create --dbhost 172.23.0.3 --database kohadb --request-db koha-demo
> $ vim koha-demo-db-request.txt
> $ koha-create --dbhost 172.23.0.3 --database kohadb --populate-db koha-demo
> Koha instance is empty, no staff user created.
> 
> after that I still see the autogenerated password in /etc/koha/sites/koha-demo/koha-conf.xml and the mariadb database is empty
> 
> after reading the koha-create source i have a feeling this --request-db/--populate-db stuff cant possibly work. --populate-db is trying to get the db passwort using getinstancemysqluser() but that function is a wrapper around xmlstarlet and i was just told by `koha-create --request-db` to write the new db password into this txt file.
>  
> I will update the wiki after I figured this out
> 
> cheers
> david
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220930/79473b20/attachment.htm>

From pjamorim91 at gmail.com  Fri Sep 30 16:11:13 2022
From: pjamorim91 at gmail.com (Pedro Amorim)
Date: Fri, 30 Sep 2022 14:11:13 +0000
Subject: [Koha-devel] Merging authority records can corrupt data
In-Reply-To: <20220930121913.GC1853016@plix.at>
References: <20220930121913.GC1853016@plix.at>
Message-ID: <CALWP7TLQjE9p2rbc05FqAxnW5afe2-dqEf4xa9nzq6HSM0QHVg@mail.gmail.com>

Hi Thomas,

Not sure if this will help but what is the value of the
*AuthorityMergeLimit* sys pref?
I think the default value is 50 and any authority being merged with more
than 50 linked biblios will be processed by the
*misc/migration_tools/merge_authority.pl
<http://merge_authority.pl>* cronjob (which runs daily by default if I'm
not mistaken).
If the problem you're experiencing is indeed related to having lots of
linked biblios, maybe lowering this value (or setting it if empty) might
help?

In the past I reported an issue with subsequent authority merging (that get
queued to be processed by the cronjob):
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22437

But I believe this has been fixed.


On Fri, 30 Sept 2022 at 12:19, Thomas Klausner <domm at plix.at> wrote:

> Hi!
>
> It seems that merging authorities with lots of linked biblios can lead
> to data corruption (at least in 21.05):
>
> The merging of the auth record itself seems to work, but the linking of
> the biblios from old to new auth record happens inside a normal
> synchrone web request. If this requests times out (because there might
> be a lot of biblio records to relink), some of the biblios still point
> to the old auth, which is already deleted. (At least this seems to be
> happening, based on the complaints we got from librarians)
>
> I guess the only fix is to handle authority merging via background jobs
> / job queue.
>
> Is this a known bug? I couldn't find anything about that in bugzilla?
> If yes, is there a timeframe when it will be fixed?
> If no, I will create a bug (though reproducing it will need some weird
> fixtures in the DB..).
>
> In any case, the Steiermärkische Landesbibliothek is keen to get this
> working, so I could give fixing it a try. But this will need some
> discussion, I assume? As I suppose this will be a bit more work than a
> single-line fix in a template, I'd like to have some backing by other
> Koha-devs, that this behaviour is indeed a bug, and that using
> background jobs is the correct way to fix it.
>
> Greetings,
> domm
>
> --
> #!/usr/bin/perl                             https://domm.plix.at
> for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220930/994950ee/attachment.htm>

From wizzyrea at gmail.com  Fri Sep 30 16:32:33 2022
From: wizzyrea at gmail.com (Liz Rea)
Date: Fri, 30 Sep 2022 09:32:33 -0500
Subject: [Koha-devel] Critical error on Koha website
In-Reply-To: <99fda852-8eec-43f8-be5d-d9d524ddd5cb@adminkuhn.ch>
References: <99fda852-8eec-43f8-be5d-d9d524ddd5cb@adminkuhn.ch>
Message-ID: <CAD+xdkR5WqqsF6szspT81J935_G8L_-sVw+d8deSRHD4ATQ8bw@mail.gmail.com>

Hi friends,

This was related to an update to Wordpress and the theme we use. Have
sorted out those issues and things are seeming better now, if you'd please
test!

Cheers,
Liz

On Thu, Sep 29, 2022 at 2:51 PM Michael Kuhn <mik at adminkuhn.ch> wrote:

> Hi
>
> When I'm trying to preview or release the current Koha newsletter I'm
> getting the following message:
>
> There has been a critical error on this website.
>
> I'm also getting this message when I try to access older newsletters,
> for example
>
> * https://koha-community.org/koha-community-newsletter-april-2022/
> * https://koha-community.org/koha-community-newsletter-august-2022/
>
> Can someone with the necessary rights and knowledge please remove this
> problem?
>
> Best wishes: Michael
> --
> Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
> Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
> T 0041 (0)61 261 55 61 · E mik at adminkuhn.ch · W www.adminkuhn.ch
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220930/0450c17f/attachment-0001.htm>

From domm at plix.at  Fri Sep 30 16:45:30 2022
From: domm at plix.at (Thomas Klausner)
Date: Fri, 30 Sep 2022 16:45:30 +0200
Subject: [Koha-devel] Merging authority records can corrupt data
In-Reply-To: <CALWP7TLQjE9p2rbc05FqAxnW5afe2-dqEf4xa9nzq6HSM0QHVg@mail.gmail.com>
References: <20220930121913.GC1853016@plix.at>
 <CALWP7TLQjE9p2rbc05FqAxnW5afe2-dqEf4xa9nzq6HSM0QHVg@mail.gmail.com>
Message-ID: <20220930144530.GE1853016@plix.at>

Hi!

On Fri, Sep 30, 2022 at 02:11:13PM +0000, Pedro Amorim wrote:
 
> Not sure if this will help but what is the value of the
> *AuthorityMergeLimit* sys pref?
> I think the default value is 50 and any authority being merged with more
> than 50 linked biblios will be processed by the
> *misc/migration_tools/merge_authority.pl
> <http://merge_authority.pl>* cronjob (which runs daily by default if I'm
> not mistaken).

I didn't know about that setting (or the cronjob), but it is set to 50. 
But we'll try to set it to a lower value (and make sure that the cronjob 
is set up).

> In the past I reported an issue with subsequent authority merging (that get
> queued to be processed by the cronjob):
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22437
> 
> But I believe this has been fixed.

ok, thanks, I'll also take a look at this bug and it's fix.

Thanks a lot!

Greetings,
domm


-- 
#!/usr/bin/perl                             https://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

From mik at adminkuhn.ch  Fri Sep 30 16:48:05 2022
From: mik at adminkuhn.ch (Michael Kuhn)
Date: Fri, 30 Sep 2022 16:48:05 +0200
Subject: [Koha-devel] Critical error on Koha website
In-Reply-To: <CAD+xdkR5WqqsF6szspT81J935_G8L_-sVw+d8deSRHD4ATQ8bw@mail.gmail.com>
References: <99fda852-8eec-43f8-be5d-d9d524ddd5cb@adminkuhn.ch>
 <CAD+xdkR5WqqsF6szspT81J935_G8L_-sVw+d8deSRHD4ATQ8bw@mail.gmail.com>
Message-ID: <12d0a09f-7839-6d75-2491-9e93d8d32062@adminkuhn.ch>

Hi Liz

You wrote:

 > This was related to an update to Wordpress and the theme we use. Have
 > sorted out those issues and things are seeming better now, if you'd
 > please test!

I noticed two things:

1. For example in 
https://koha-community.org/koha-community-newsletter-september-2022/ I 
am using HTML headings <h2>, <h3> and <h4> - they should all use a 
larger font size than the normal writing. h2 should be larger than h3, 
h3 should be larger than h4. At the moment h4 seems to be larger than 
h3. (or did you just change that some minutes ago?)

2. For example in https://koha-community.org/koha-22-05-05-released/ I 
have noticed many wrong special characters, you can best see this in 
section "Credits" ath the end where many names are mutilated, like

Tomás Cohen Arazi (10)
Jérémy Breuillard (1)
Frédéric Demians (1)
Joonas Kylmälä (2)
Adolfo Rodríguez (1)
etc.

Seems like Wordpress isn't using proper UTF-8.

Best wishes: Michael
-- 
Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
T 0041 (0)61 261 55 61 · E mik at adminkuhn.ch · W www.adminkuhn.ch



> On Thu, Sep 29, 2022 at 2:51 PM Michael Kuhn <mik at adminkuhn.ch 
> <mailto:mik at adminkuhn.ch>> wrote:
> 
>     Hi
> 
>     When I'm trying to preview or release the current Koha newsletter I'm
>     getting the following message:
> 
>     There has been a critical error on this website.
> 
>     I'm also getting this message when I try to access older newsletters,
>     for example
> 
>     * https://koha-community.org/koha-community-newsletter-april-2022/
>     <https://koha-community.org/koha-community-newsletter-april-2022/>
>     * https://koha-community.org/koha-community-newsletter-august-2022/
>     <https://koha-community.org/koha-community-newsletter-august-2022/>
> 
>     Can someone with the necessary rights and knowledge please remove this
>     problem?
> 
>     Best wishes: Michael
>     -- 
>     Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
>     Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
>     T 0041 (0)61 261 55 61 · E mik at adminkuhn.ch
>     <mailto:mik at adminkuhn.ch> · W www.adminkuhn.ch <http://www.adminkuhn.ch>
>     _______________________________________________
>     Koha-devel mailing list
>     Koha-devel at lists.koha-community.org
>     <mailto:Koha-devel at lists.koha-community.org>
>     https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>     <https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel>
>     website : https://www.koha-community.org/
>     <https://www.koha-community.org/>
>     git : https://git.koha-community.org/ <https://git.koha-community.org/>
>     bugs : https://bugs.koha-community.org/
>     <https://bugs.koha-community.org/>
> 



From mik at adminkuhn.ch  Fri Sep 30 18:52:57 2022
From: mik at adminkuhn.ch (Michael Kuhn)
Date: Fri, 30 Sep 2022 18:52:57 +0200
Subject: [Koha-devel] Excess fields in Koha 22.05 file "patron_import.csv"
Message-ID: <26ae08d7-635c-13e3-3561-a96affd78f90@adminkuhn.ch>

Hi

When unloading the field names of Koha 22.05 table "borrowers" I get 79 
field names (plus "borrowernumber").

But when in Koha 22.05 menu "Tools > Import patrons" I click the link 
"Starter CSV file" the unloaded file "patron_import.csv" does include 82 
fields.

When comparing the two outputs I see there are three more fields in file 
"patron_import.csv" than in table "borrowers":

  patron_attributes
  guarantor_relationship
  guarantor_id

These three fields aren't included in 
https://schema.koha-community.org/22_05/tables/borrowers.html

What is the explanation for these excess fields?

Best wishes: Michael
-- 
Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
T 0041 (0)61 261 55 61 · E mik at adminkuhn.ch · W www.adminkuhn.ch

From indradg at l2c2.co.in  Fri Sep 30 19:00:41 2022
From: indradg at l2c2.co.in (Indranil Das Gupta)
Date: Fri, 30 Sep 2022 22:30:41 +0530
Subject: [Koha-devel] Excess fields in Koha 22.05 file
 "patron_import.csv"
In-Reply-To: <26ae08d7-635c-13e3-3561-a96affd78f90@adminkuhn.ch>
References: <26ae08d7-635c-13e3-3561-a96affd78f90@adminkuhn.ch>
Message-ID: <CAJ0y-DfB_QAL0t8DqDSuHmO71b4QY136c8dBK2=M51nM8oHEpg@mail.gmail.com>

Hi Michael,

Their mapping as follows

For patron_attributes -
https://schema.koha-community.org/22_05/tables/borrower_attributes.html

For "guarantor_relationship" and "guarantor_id" -
https://schema.koha-community.org/22_05/tables/borrower_relationships.html

hope this helps

Indranil Das Gupta
L2C2 Technologies

Phone : +91-98300-20971
WWW : http://www.l2c2.co.in
Blog    : http://blog.l2c2.co.in
IRC     : indradg on irc://irc.freenode.net
Twitter : indradg

-- 
Indranil Das Gupta
L2C2 Technologies

Phone : +91-98300-20971
WWW : http://www.l2c2.co.in
Blog    : http://blog.l2c2.co.in
IRC     : indradg on irc://irc.freenode.net
Twitter : indradg


On Fri, 30 Sept 2022 at 22:23, Michael Kuhn <mik at adminkuhn.ch> wrote:
>
> Hi
>
> When unloading the field names of Koha 22.05 table "borrowers" I get 79
> field names (plus "borrowernumber").
>
> But when in Koha 22.05 menu "Tools > Import patrons" I click the link
> "Starter CSV file" the unloaded file "patron_import.csv" does include 82
> fields.
>
> When comparing the two outputs I see there are three more fields in file
> "patron_import.csv" than in table "borrowers":
>
>   patron_attributes
>   guarantor_relationship
>   guarantor_id
>
> These three fields aren't included in
> https://schema.koha-community.org/22_05/tables/borrowers.html
>
> What is the explanation for these excess fields?
>
> Best wishes: Michael
> --
> Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
> Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
> T 0041 (0)61 261 55 61 · E mik at adminkuhn.ch · W www.adminkuhn.ch
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/