<!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 7511 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 25<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> 2. Re: Enable libraries to moderate OPAC self-registrations<br> (Tomas Cohen Arazi)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Wed, 31 Aug 2022 12:48:42 +1200<br>From: Alex Buckley <alexbuckley@catalyst.net.nz><br>To: dcook@prosentient.com.au, koha-devel@lists.koha-community.org<br>Subject: Re: [Koha-devel] Enable libraries to moderate OPAC<br> self-registrations<br>Message-ID: <1fe1b120-9614-5905-8f33-0eb9b75e99ab@catalyst.net.nz><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi David,<br><br>Thanks very much for your reply. I'm glad you like the idea of<br>moderating OPAC self-registrations.<br><br>Yes, as you say we could use the borrower_modifications table. Adding an<br>auto-number primary key and making borrower_modifications.borrowernumber<br>nullable. Then when a user self registered a row is added to the<br>borrower_modifications table with a null borrowernumber, and no<br>cardnumber, userid and password.<br><br>If approved the row could be shifted to the borrowers table with a<br>borrowernumber, cardnumber, userid set. The password could be set by the<br>new borrower via the password reset link emailed to them.<br><br>I'm not sure if it is 'cleaner' to re-work the existing<br>borrower_modifications table or make a new database table. I might try<br>out with both locally and see how it goes, unless anyone else has strong<br>opinions on this?<br><br>A generic pending_action table sounds like a great long term goal for<br>sure! I think for bug 25090 if I do go with a new table it would only be<br>for OPAC self registrations though.<br><br>Thanks again for your thoughts and yes if you would be happy to test<br>once it is ready that would be amazing!<br><br>Kind regards,<br><br>Alex<br><br><br>On 30/08/22 16:22, dcook@prosentient.com.au wrote:<br>><br>> Hi Alex,<br>><br>> <br>><br>> Overall, I like the idea of moderating OPAC self-registrations.<br>><br>> <br>><br>> Locally, we customize the self-registration to add a restriction to<br>> new borrowers, and email the library that there is a pending<br>> self-registration. But I think you make a good point about the<br>> accessing of electronic content.<br>><br>> <br>><br>> At a glance, it doesn’t look like you could use the<br>> borrower_modifications table at present since it requires a<br>> borrowernumber.<br>><br>> <br>><br>> Maybe one option would be to create the OPAC patron account but<br>> without a cardnumber, userid, or password (which you could then<br>> provide via borrower_modifications)? I suppose though that user could<br>> still be found by some APIs and that might still let them get too far.<br>> It looks like borrower_modifications is missing an autonumber primary<br>> key… that could be added and then borrowernumber could potentially be<br>> made nullable?<br>><br>> <br>><br>> If you don’t alter borrower_modifications, then you probably need a<br>> new table.<br>><br>> <br>><br>> I wonder about a generic “pending_action” table that incorporated a<br>> lot of the tracking of “suggestions”, and then a linking table of<br>> “pending_action_borrower_registrations”, and then a table of<br>> “borrower_registrations”. (In theory, eventually “suggestions” and<br>> “borrower_modifications” could be refactored to hook into this more<br>> generic system, and pave the way for easily adding other “pending<br>> actions” that need to be moderated. In fact… I think there is a<br>> moderation/review process for “reviews” (also known as Comments I<br>> think?)… “problem_reports” could’ve benefitted from that too.<br>> Hypothetically even “tags_approval”. That’s all a bit grand though.<br>><br>> <br>><br>> I’d be interested in testing whatever you come up with in any case.<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:* Tuesday, 30 August 2022 8:46 AM<br>> *To:* koha-devel@lists.koha-community.org<br>> *Subject:* [Koha-devel] Enable libraries to moderate OPAC<br>> self-registrations<br>><br>> <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 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 log<br>> into the OPAC.<br>><br>> Step 3: A pending registration link appears at the bottom of the staff<br>> client home page (like what's currently done with new purchase<br>> suggestions, or OPAC patron modification requests).<br>><br>> Step 4: Librarians can click on the link to go to a page to approve or<br>> 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 having<br>> anyone from around the world self-registering for a library OPAC login<br>> and accessing electronic content from some providers, therefore,<br>> incurring extra costs for the library.<br>><br>> Bug 25090 was originally developed in the early days of the pandemic<br>> to ensure new self-registering OPAC users accessing 3rd party<br>> databases were coming from acceptable locations i.e. they were members<br>> 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 modification<br>> requests?<br>><br>> Q3: How would you envisage this self-registration moderation feature<br>> fitting in with the existing PatronSelfRegistrationVerifyByEmail and<br>> PatronSelfRegistrationDefaultCategory sysprefs?<br>><br>> Any thoughts much appreciated.<br>><br>> Kind regards,<br>><br>> Alex<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/c3cf6df7/attachment-0001.htm><br><br>------------------------------<br><br>Message: 2<br>Date: Tue, 30 Aug 2022 23:35:08 -0300<br>From: Tomas Cohen Arazi <tomascohen@gmail.com><br>To: Alex Buckley <alexbuckley@catalyst.net.nz><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:<br> <CABZfb=U7XMt4d3Mf1Vh1Fgm_iuGboUYd62icxbZLn1jqEjfHBw@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Please, use a separate table. And think of the request workflow handling in<br>the db, the statuses (as enum), how it will be handled at library or<br>library group level. Even if not implemented at this stage. Also, maybe you<br>need more than one table, don't fear adding tables if they make sense and<br>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 issues as<br>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> ( Moderate<br>> OPAC self-registrations before a patron account is 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 patron<br>> account is not created immediately - i.e. they cannot yet log into the OPAC.<br>><br>> Step 3: A pending registration link appears at the bottom of the staff<br>> client home page (like what's currently done with new purchase suggestions,<br>> or OPAC patron modification requests).<br>><br>> Step 4: Librarians can click on the link to go to a page to approve or<br>> decline the registration.<br>><br>> Step 4a: If approved the user is sent an email notice, containing their<br>> 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 - by<br>> using the PatronSelfRegistrationDefaultCategory syspref and creating<br>> circulation rule(s) for that category.<br>><br>> However, users only need an OPAC login (without the ability to circulate)<br>> to access electronic content providers (integrated with Koha via<br>> STunnel/SIP2). Some electronic content providers charge libraries based on<br>> their usage. Meaning it might not be optimal having anyone from around the<br>> world self-registering for a library OPAC login and accessing electronic<br>> content from some providers, therefore, incurring extra costs for the<br>> library.<br>><br>> Bug 25090 was originally developed in the early days of the pandemic to<br>> ensure new self-registering OPAC users accessing 3rd party databases were<br>> coming from acceptable locations i.e. they were members of the organisation<br>> 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>> *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 self-registrations<br>> awaiting approval, or should I use the borrowers_modifications table - as<br>> is used by OPAC patron modification requests?<br>><br>> Q3: How would you envisage this self-registration moderation feature<br>> fitting in with the existing PatronSelfRegistrationVerifyByEmail and PatronSelfRegistrationDefaultCategory<br>> sysprefs?<br>><br>> Any thoughts much appreciated.<br>><br>> Kind regards,<br>><br>> Alex<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>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220830/a35ebcb2/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 201, Issue 25<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>