<!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 7233 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 15<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: Thu, 15 Sep 2022 09:20:43 +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: <f5e94340-ab01-5a22-95f3-16de5aa6c4c3@catalyst.net.nz><br>Content-Type: text/plain; charset="utf-8"<br><br>Thanks Tomas!<br><br>On 13/09/22 00:34, Tomas Cohen Arazi wrote:<br>> I'm not planning to work on that in a short term.<br>><br>> El lun, 12 sept 2022 a las 5:20, Alex Buckley<br>> (<alexbuckley@catalyst.net.nz>) escribió:<br>><br>>     Good point Tomas. <br>><br>>     An unmoderated patron registration would be like a staged (but not<br>>     imported) patron record.<br>><br>>     I see you created a bug report for that functionality on<br>>     https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20916<br>><br>>     Were you planning on working on that or is it available for others<br>>     to work on it?<br>><br>><br>>     On 7/09/22 03:04, Tomas Cohen Arazi wrote:<br>>>     I think we need to resurrect the idea of a patron import<br>>>     staging + import step. This one being a particular use case.<br>>><br>>>     El mar, 6 sept 2022 a las 7:43, Katrin Fischer<br>>>     (<katrin.fischer.83@web.de>) escribió:<br>>><br>>>         Hi all,<br>>><br>>>         I think the feature would be useful. :)<br>>><br>>>         I feel there has been some misunderstanding about the<br>>>         borrower_modifications table. It doesn't require a valid<br>>>         borrowernumber as the table is used for at least 2 purposes<br>>>         already:<br>>><br>>>         * Patron data modification requests from the OPAC<br>>>         (borrowernumber of patron)<br>>><br>>>         * Patron self registrations with required email verification<br>>>         (borrowernumber = 0)<br>>><br>>>         It's used as a temporary storage for patron data and I am not<br>>>         sure if a separate table would makes sense as the table<br>>>         structure would probably be really similar. We already need<br>>>         to keep 3 tables in sync when adding columns: borrowers,<br>>>         deletedborrowers, borrower_modifications. We might also want<br>>>         to think about how the data will move when email verification<br>>>         is used in addition to moderation.<br>>><br>>>         Hope this helps,<br>>><br>>>         Katrin<br>>><br>>>         On 31.08.22 04:35, Tomas Cohen Arazi wrote:<br>>>>         Please, use a separate table. And think of the request<br>>>>         workflow handling in the db, the statuses (as enum), how it<br>>>>         will be handled at library or library group level. Even if<br>>>>         not implemented at this stage. Also, maybe you need more<br>>>>         than one table, don't fear adding tables if they make sense<br>>>>         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<br>>>>         design issues as it points to the classes you will need.<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 page<br>>>>             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 email<br>>>>             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). Some<br>>>>             electronic content providers charge libraries based on<br>>>>             their usage. Meaning it might not be optimal having<br>>>>             anyone from around the world self-registering for a<br>>>>             library OPAC login and accessing electronic content from<br>>>>             some providers, therefore, incurring extra costs for the<br>>>>             library.<br>>>><br>>>>             Bug 25090 was originally developed in the early days of<br>>>>             the pandemic to ensure new self-registering OPAC users<br>>>>             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>>>>             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>>>>         _______________________________________________<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>>>         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>>>     Tomás Cohen Arazi<br>>>     Theke Solutions (http://theke.io)<br>>>     ✆ +54 9351 3513384<br>>>     GPG: B2F3C15F<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>><br>><br>><br>> -- <br>> Tomás Cohen Arazi<br>> Theke Solutions (http://theke.io)<br>> ✆ +54 9351 3513384<br>> GPG: B2F3C15F<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/20220915/fc77d296/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 15<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>