<!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 7512 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is : <br><br>Title : Koha-devel Digest, Vol 201, Issue 26<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: Wed, 31 Aug 2022 16:32:58 +1200<br>From: Alex Buckley <alexbuckley@catalyst.net.nz><br>To: Tomas Cohen Arazi <tomascohen@gmail.com><br>Cc: koha-devel <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] Enable libraries to moderate OPAC<br>    self-registrations<br>Message-ID: <7d13ac6a-6fec-9526-a514-d1aece591f22@catalyst.net.nz><br>Content-Type: text/plain; charset="utf-8"<br><br>Thanks for that Tomas, I appreciate it. I will add a separate table(s)<br>and will have a think about what you have noted.<br><br>Kind regards,<br><br>Alex<br><br><br>On 31/08/22 14:35, Tomas Cohen Arazi wrote:<br>> Please, use a separate table. And think of the request workflow<br>> handling in the db, the statuses (as enum), how it will be handled at<br>> library or library group level. Even if not implemented at this stage.<br>> Also, maybe you need more than one table, don't fear adding tables if<br>> they make sense and give us a cleaner implementation.<br>><br>> Moderation should be traceable, etc.<br>><br>> Thinking of API routes for the process usually clears the design<br>> issues as it points to the classes you will need.<br>><br>> El lun, 29 ago 2022 19:46, Alex Buckley <alexbuckley@catalyst.net.nz><br>> 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 account is<br>>     created ).<br>><br>>     *New proposed functionality:*<br>><br>>     Step 1: The library enables both the new<br>>     'PatronSelfRegistrationModeration' syspref and the existing<br>>     'OpacResetPassword'syspref.<br>><br>>     Step 2: When a user submits an OPAC self-registration their Koha<br>>     patron account is not created immediately - i.e. they cannot yet<br>>     log into the OPAC.<br>><br>>     Step 3: A pending registration link appears at the bottom of the<br>>     staff client home page (like what's currently done with new<br>>     purchase suggestions, or OPAC patron modification requests).<br>><br>>     Step 4: Librarians can click on the link to go to a page to<br>>     approve or decline the registration.<br>><br>>     Step 4a: If approved the user is sent an email notice, containing<br>>     their Koha username and an OPAC reset password link.<br>><br>>     Step 4b: If declined the user is sent a different email notice.<br>><br>>     *The rationale for adding this feature:*<br>>     You can currently limit the circulation of self-registered patrons<br>>     - by using the PatronSelfRegistrationDefaultCategory syspref and<br>>     creating circulation rule(s) for that category.<br>><br>>     However, users only need an OPAC login (without the ability to<br>>     circulate) to access electronic content providers (integrated with<br>>     Koha via STunnel/SIP2). Some electronic content providers charge<br>>     libraries based on their usage. Meaning it might not be optimal<br>>     having anyone from around the world self-registering for a library<br>>     OPAC login and accessing electronic content from some providers,<br>>     therefore, incurring extra costs for the library.<br>><br>>     Bug 25090 was originally developed in the early days of the<br>>     pandemic to ensure new self-registering OPAC users accessing 3rd<br>>     party databases were coming from acceptable locations i.e. they<br>>     were members of the 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 the<br>>     borrowers_modifications table - as is used by OPAC patron<br>>     modification requests?<br>><br>>     Q3: How would you envisage this self-registration moderation<br>>     feature fitting in with the existing <br>>     PatronSelfRegistrationVerifyByEmailand<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>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/20220831/fffa4c15/attachment-0001.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 201, Issue 26<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>