<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body>A new request with request id 7592 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is : <br><br>Title : Koha-devel Digest, Vol 202, Issue 4<br>Category : <br>Description : <div>Send Koha-devel mailing list submissions to<br> koha-devel@lists.koha-community.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>or, via email, send a message with subject or body 'help' to<br> koha-devel-request@lists.koha-community.org<br><br>You can reach the person managing the list at<br> koha-devel-owner@lists.koha-community.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of Koha-devel digest..."<br><br><br>Today's Topics:<br><br> 1. Re: Enable libraries to moderate OPAC self-registrations<br> (Alex Buckley)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Mon, 5 Sep 2022 12:26:18 +1200<br>From: Alex Buckley <alexbuckley@catalyst.net.nz><br>To: dcook@prosentient.com.au, 'Arthur' <arthur.suzuki@biblibre.com>,<br> 'koha-devel' <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] Enable libraries to moderate OPAC<br> self-registrations<br>Message-ID: <54a1fb34-e416-9b13-8a2f-e75cb6d8cb68@catalyst.net.nz><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi David,<br><br>Thanks for your response. I think what you outline would work for our<br>use case and would be a good first step to be upstreamed also.<br><br>I feel like adding the functionality of giving librarians the ability to<br>moderate self-registrations could still be a good end goal for Koha - so<br>that the self registration behaviour could be more consistent with OPAC<br>patron self edit request behaviour. <br><br>Could you please let me know how have you locally configured SIP to not<br>allow login for restricted patrons?<br><br>Kind regards,<br><br>Alex<br><br><br>On 2/09/22 11:42, dcook@prosentient.com.au wrote:<br>><br>> You know one option would be to add a Restriction/Debarment to the<br>> user on self-registration (like we do locally) and then make sure that<br>> SIP doesn’t allow login for restricted patrons (I notice that is what<br>> we do locally as well).<br>><br>> <br>><br>> It wouldn’t meet all use cases, but it could work for yours.<br>><br>> <br>><br>> David Cook<br>><br>> Senior Software Engineer<br>><br>> Prosentient Systems<br>><br>> Suite 7.03<br>><br>> 6a Glen St<br>><br>> Milsons Point NSW 2061<br>><br>> Australia<br>><br>> <br>><br>> Office: 02 9212 0899<br>><br>> Online: 02 8005 0595<br>><br>> <br>><br>> *From:*Koha-devel <koha-devel-bounces@lists.koha-community.org> *On<br>> Behalf Of *Alex Buckley<br>> *Sent:* Thursday, 1 September 2022 3:40 PM<br>> *To:* Arthur <arthur.suzuki@biblibre.com>; koha-devel<br>> <koha-devel@lists.koha-community.org><br>> *Subject:* Re: [Koha-devel] Enable libraries to moderate OPAC<br>> self-registrations<br>><br>> <br>><br>> Hi Arthur,<br>><br>> Thanks very much for your reply. Very interesting idea!<br>><br>> Are the electronic resources that you hide with Bokeh the links in<br>> biblio 856$u subfields?<br>><br>> To give you some more context, one of the reasons this feature was<br>> proposed was that as soon as patrons have a Koha userid and password<br>> then they could authenticate (via Stunnel/SIP2) to electronic<br>> platforms linked from the OpacNav HTML customisations on the OPAC home<br>> page.<br>><br>> Meaning if the OPAC has OPACPublic='Enable' then electronic resource<br>> platform links in HTML customisations would be visible on the OPAC<br>> home page and, therefore, accessible to all users regardless of their<br>> patron category.<br>><br>> Having some ability for libraries to moderate registrations, before<br>> those users have a userid and password, would restrict whether they<br>> could authenticate to these electronic platforms via Stunnel/SIP2.<br>><br>> Thanks,<br>><br>> Alex<br>><br>> <br>><br>> On 1/09/22 01:01, Arthur wrote:<br>><br>> Hi Alex (&folks)<br>><br>> What about the electronic ressources uses the Koha<br>> groups/patron_category to allow or deny access to the resource?<br>><br>> Then if newly created patrons have a specific default category,<br>> then this category could be denied access to electronic resources.<br>><br>> We've done this way for our frontend software (Bokeh) and it works<br>> quite well. Upon login, the patron category is received.<br>><br>> Depending on the category, the user can see the links to<br>> electronic resource or not. Also the electronic resource server<br>> checks the category against Koha using CAS attributes.<br>><br>> Cheers,<br>><br>> Arthur<br>><br>> On 31/08/2022 06:32, Alex Buckley wrote:<br>><br>> Thanks for that Tomas, I appreciate it. I will add a separate<br>> table(s) and will have a think about what you have noted.<br>><br>> Kind regards,<br>><br>> Alex<br>><br>> <br>><br>> On 31/08/22 14:35, Tomas Cohen Arazi wrote:<br>><br>> Please, use a separate table. And think of the request<br>> workflow handling in the db, the statuses (as enum), how<br>> it will be handled at library or library group level. Even<br>> if not implemented at this stage. Also, maybe you need<br>> more than one table, don't fear adding tables if they make<br>> sense and give us a cleaner implementation.<br>><br>> <br>><br>> Moderation should be traceable, etc.<br>><br>> <br>><br>> Thinking of API routes for the process usually clears the<br>> design issues as it points to the classes you will need.<br>><br>> <br>><br>> El lun, 29 ago 2022 19:46, Alex Buckley<br>> <alexbuckley@catalyst.net.nz> escribió:<br>><br>> Kia ora/Hello Koha community,<br>><br>> I am currently working on reviving bug 25090<br>> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25090><br>> ( Moderate OPAC self-registrations before a patron<br>> account is created ).<br>><br>> *New proposed functionality:*<br>><br>> Step 1: The library enables both the new<br>> 'PatronSelfRegistrationModeration' syspref and the<br>> existing 'OpacResetPassword' syspref.<br>><br>> Step 2: When a user submits an OPAC self-registration<br>> their Koha patron account is not created immediately -<br>> i.e. they cannot yet log into the OPAC.<br>><br>> Step 3: A pending registration link appears at the<br>> bottom of the staff client home page (like what's<br>> currently done with new purchase suggestions, or OPAC<br>> patron modification requests).<br>><br>> Step 4: Librarians can click on the link to go to a<br>> page to approve or decline the registration.<br>><br>> Step 4a: If approved the user is sent an email notice,<br>> containing their Koha username and an OPAC reset<br>> password link.<br>><br>> Step 4b: If declined the user is sent a different<br>> email notice.<br>><br>> *The rationale for adding this feature:*<br>> You can currently limit the circulation of<br>> self-registered patrons - by using the<br>> PatronSelfRegistrationDefaultCategory syspref and<br>> creating circulation rule(s) for that category.<br>><br>> However, users only need an OPAC login (without the<br>> ability to circulate) to access electronic content<br>> providers (integrated with Koha via STunnel/SIP2).<br>> Some electronic content providers charge libraries<br>> based on their usage. Meaning it might not be optimal<br>> having anyone from around the world self-registering<br>> for a library OPAC login and accessing electronic<br>> content from some providers, therefore, incurring<br>> extra costs for the library.<br>><br>> Bug 25090 was originally developed in the early days<br>> of the pandemic to ensure new self-registering OPAC<br>> users accessing 3rd party databases were coming from<br>> acceptable locations i.e. they were members of the<br>> organisation the library is in.<br>><br>> More details can be found here:<br>> https://www.catalyst.net.nz/blog/mental-health-education-resource-library-now-offers-online-self-registration<br>><br>> *Questions I would like to hear your thoughts on please:*<br>><br>> Q1: Are you in favour of this as a new feature in Koha?<br>><br>> Q2: Would you prefer a new database table be added for<br>> self-registrations awaiting approval, or should I use<br>> the borrowers_modifications table - as is used by OPAC<br>> patron modification requests?<br>><br>> Q3: How would you envisage this self-registration<br>> moderation feature fitting in with the existing <br>> PatronSelfRegistrationVerifyByEmail and<br>> PatronSelfRegistrationDefaultCategory sysprefs?<br>><br>> Any thoughts much appreciated.<br>><br>> Kind regards,<br>><br>> Alex<br>><br>> _______________________________________________<br>> Koha-devel mailing list<br>> Koha-devel@lists.koha-community.org<br>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>> website : https://www.koha-community.org/<br>> git : https://git.koha-community.org/<br>> bugs : https://bugs.koha-community.org/<br>><br>> -- <br>><br>> Alex Buckley<br>><br>> Koha Developer | Implementation Lead<br>><br>> Catalyst IT - Expert Open Source Solutions<br>><br>> <br>><br>> Catalyst.Net Ltd - a Catalyst IT group company<br>><br>> <br>><br>> CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.<br>><br>> It may contain privileged, confidential or copyright information. If you are not<br>><br>> the named recipient, any use, reliance upon, disclosure or copying of this email<br>><br>> or its attachments is unauthorised. If you have received this email in error,<br>><br>> please reply via email or call +64 4 499 2267.<br>><br>><br>><br>> _______________________________________________<br>><br>> Koha-devel mailing list<br>><br>> Koha-devel@lists.koha-community.org<br>><br>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>><br>> website : https://www.koha-community.org/<br>><br>> git : https://git.koha-community.org/<br>><br>> bugs : https://bugs.koha-community.org/<br>><br>><br>><br>> _______________________________________________<br>><br>> Koha-devel mailing list<br>><br>> Koha-devel@lists.koha-community.org<br>><br>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>><br>> website : https://www.koha-community.org/<br>><br>> git : https://git.koha-community.org/<br>><br>> bugs : https://bugs.koha-community.org/<br>><br>> -- <br>> Alex Buckley<br>> Koha Developer | Implementation Lead<br>> Catalyst IT - Expert Open Source Solutions<br>> <br>> Catalyst.Net Ltd - a Catalyst IT group company<br>> <br>> CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.<br>> It may contain privileged, confidential or copyright information. If you are not<br>> the named recipient, any use, reliance upon, disclosure or copying of this email<br>> or its attachments is unauthorised. If you have received this email in error,<br>> please reply via email or call +64 4 499 2267.<br><br>-- <br>Alex Buckley<br>Koha Developer | Implementation Lead<br>Catalyst IT - Expert Open Source Solutions<br><br>Catalyst.Net Ltd - a Catalyst IT group company<br><br>CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.<br>It may contain privileged, confidential or copyright information. If you are not<br>the named recipient, any use, reliance upon, disclosure or copying of this email<br>or its attachments is unauthorised. If you have received this email in error,<br>please reply via email or call +64 4 499 2267.<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220905/1d44fe35/attachment.htm><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>Koha-devel mailing list<br>Koha-devel@lists.koha-community.org<br>https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>website : https://www.koha-community.org/<br>git : https://git.koha-community.org/<br>bugs : https://bugs.koha-community.org/<br><br><br>------------------------------<br><br>End of Koha-devel Digest, Vol 202, Issue 4<br>******************************************<br></div><br><br>NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.<br></body></html>