A new request with request id 7537 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is :

Title : Koha-devel Digest, Vol 202, Issue 1
Category :
Description :
Send Koha-devel mailing list submissions to
    koha-devel@lists.koha-community.org

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
or, via email, send a message with subject or body 'help' to
    koha-devel-request@lists.koha-community.org

You can reach the person managing the list at
    koha-devel-owner@lists.koha-community.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Koha-devel digest..."


Today's Topics:

1. Re: Enable libraries to moderate OPAC self-registrations (Arthur)
2. Re: Enable libraries to moderate OPAC self-registrations
(Alex Buckley)


----------------------------------------------------------------------

Message: 1
Date: Wed, 31 Aug 2022 15:01:59 +0200
From: Arthur <arthur.suzuki@biblibre.com>
To: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] Enable libraries to moderate OPAC
    self-registrations
Message-ID: <a5a23b3b-e50e-ee63-79a0-5a9781baa158@biblibre.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

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@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@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@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/20220831/27ad1fb8/attachment-0001.htm>

------------------------------

Message: 2
Date: Thu, 1 Sep 2022 17:39:47 +1200
From: Alex Buckley <alexbuckley@catalyst.net.nz>
To: Arthur <arthur.suzuki@biblibre.com>, koha-devel
    <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] Enable libraries to moderate OPAC
    self-registrations
Message-ID: <84a5b948-29dd-599f-5f07-692d496f1b19@catalyst.net.nz>
Content-Type: text/plain; charset="utf-8"

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@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@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@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@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.htm>

------------------------------

Subject: Digest Footer

_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/


------------------------------

End of Koha-devel Digest, Vol 202, Issue 1
******************************************


NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.