<!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 7393 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 13<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> (Tomas Cohen Arazi)<br> 2. Call for news - Newsletter September 2022 (Koha Newsletter)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Mon, 12 Sep 2022 09:34:50 -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=Xx4Yqin0=DVhu3+3g0ROoA_pSs-FWydKcx-7Bu2Bf36w@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><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 (<alexbuckley@catalyst.net.nz>)<br>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 to work<br>> on it?<br>><br>><br>> On 7/09/22 03:04, Tomas Cohen Arazi wrote:<br>><br>> I think we need to resurrect the idea of a patron import staging + import<br>> step. This one being a particular use case.<br>><br>> El mar, 6 sept 2022 a las 7:43, Katrin Fischer (<katrin.fischer.83@web.de>)<br>> 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 borrowernumber as<br>>> the table is used for at least 2 purposes already:<br>>><br>>> * Patron data modification requests from the OPAC (borrowernumber of<br>>> 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 sure if a<br>>> separate table would makes sense as the table structure would probably be<br>>> really similar. We already need to keep 3 tables in sync when adding<br>>> columns: borrowers, deletedborrowers, borrower_modifications. We might also<br>>> want to think about how the data will move when email verification is used<br>>> in addition to moderation.<br>>><br>>> Hope this helps,<br>>><br>>> Katrin<br>>> On 31.08.22 04:35, Tomas Cohen Arazi wrote:<br>>><br>>> Please, use a separate table. And think of the request workflow handling<br>>> in 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<br>>> 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> ( 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<br>>>> circulate) 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<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 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>>><br>>> _______________________________________________<br>>> Koha-devel mailing listKoha-devel@lists.koha-community.orghttps://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>>> 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 listKoha-devel@lists.koha-community.orghttps://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>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220912/0dfc49f5/attachment-0001.htm><br><br>------------------------------<br><br>Message: 2<br>Date: Tue, 13 Sep 2022 09:08:16 +0200<br>From: Koha Newsletter <kohanews@gmail.com><br>To: koha <koha@lists.katipo.co.nz>, koha-devel<br> <koha-devel@lists.koha-community.org><br>Subject: [Koha-devel] Call for news - Newsletter September 2022<br>Message-ID:<br> <CAEqgz_=GjR7tbn4oan0piL203ddfO_5ujJzx=MbfPvxiDdStJA@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>I'm collecting news for this month's newsletter. Send anything noteworthy to:<br><br>kohanews (at) gmail (dot) com<br><br>News criteria:<br>--------------<br><br>* News items can be of any length, images are fine.<br>* Please send your text in plain text or as simple HTML (no Word /<br>Google documents etc)<br>* Anything and everything Koha.<br>* Submit by the 26th of the month.<br><br>For events:<br>* Please include dates for past events. One month back is the cut-off.<br>* Announcements for future events with dates to be announced are fine,<br>e. g. Kohacon.<br><br>If you are working on an interesting project or development related to<br>Koha, please let me know and I'll include it in the development<br>section.<br><br>Thank you!<br><br>Michael Kuhn<br>Editor, Koha Community Newsletter<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220913/59a5efeb/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 13<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>