<!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 7381 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 11<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: Elasticsearch not auto-updating after cataloguing<br> (Tomas Cohen Arazi)<br> 2. Re: Enable libraries to moderate OPAC self-registrations<br> (Alex Buckley)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Sun, 11 Sep 2022 21:47:03 -0500<br>From: Tomas Cohen Arazi <tomascohen@gmail.com><br>To: Philippe Blouin <philippe.blouin@inlibro.com><br>Cc: koha-devel <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] Elasticsearch not auto-updating after<br> cataloguing<br>Message-ID:<br> <CABZfb=VDSn6g=aFNG3QCENJyuEHOutYh3ooDk=+_jga3z4gNEg@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Is koha-worker running?<br><br>El vie, 9 sept 2022 12:42, Philippe Blouin <philippe.blouin@inlibro.com><br>escribió:<br><br>> Hello kohaers!<br>><br>> Simply put: our production servers installation work very fine, each<br>> change into a record is immediately reindexed into ES.<br>><br>> BUT on laptop (ubuntu 20 or 22), the reindexing never occurs. We have to<br>> call rebuild_elasticsearch.pl manually so the search finds anything. The<br>> configuration refers to a remote ES server (instead of localhost like the<br>> prod servers), but I don't see how that would make a difference since that<br>> works once rebuilt.<br>><br>> Any clue on what I'm missing would be greatly appreciated.<br>><br>> Best regards,<br>> --<br>> Philippe Blouin,<br>> Directeur de la technologie<br>><br>> Tél. : (833) 465-4276, poste 230<br>> philippe.blouin@inLibro.com<br>> inLibro | pour esprit libre | www.inLibro.com<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/20220911/d0833231/attachment-0001.htm><br><br>------------------------------<br><br>Message: 2<br>Date: Mon, 12 Sep 2022 20:20:40 +1200<br>From: Alex Buckley <alexbuckley@catalyst.net.nz><br>To: Katrin Fischer <katrin.fischer.83@web.de><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: <69125c6d-3531-f6e2-f9cf-e4fec00abfbf@catalyst.net.nz><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi Katrin,<br><br>Thanks so much for your response. Glad to hear you thought this would be<br>a useful feature :)<br><br>Thanks also for clarifying the use of the borrowernumber in the<br>borrower_modifications table.<br><br>I agree with Tomas in regards to having a new table(s) would make for a<br>cleaner implementation, but then you raise a good point about how a new<br>table could need to have a similar structure to borrowers,<br>deletedborrowers and borrowers_modifications.<br><br>Would it be considered problematic from a QA point of view to add a new<br>table that will have to be kept in sync every time new columns are added<br>to the borrowers table?<br><br>My thoughts regarding how data could flow when email verification is<br>used, in addition to moderation, were that after a patron registration<br>was approved it was only shifted to the borrowers table when the email<br>is verified - essentially keeping some of the current workflow. But<br>happy to do otherwise if you have anything in mind here?<br><br>Kind regards,<br><br>Alex<br><br><br>On 7/09/22 02:42, Katrin Fischer wrote:<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 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<br>> a separate table would makes sense as the table structure would<br>> probably be really similar. We already need to keep 3 tables in sync<br>> when adding columns: borrowers, deletedborrowers,<br>> borrower_modifications. We might also want to think about how the data<br>> will move when email verification 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 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<br>>> stage. Also, maybe you need more than one table, don't fear adding<br>>> tables if 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<br>>> patrons - by using the PatronSelfRegistrationDefaultCategory<br>>> syspref and 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<br>>> with Koha via STunnel/SIP2). Some electronic content providers<br>>> charge libraries based on their usage. Meaning it might not be<br>>> optimal having anyone from around the world self-registering for<br>>> a library OPAC login and accessing electronic content from some<br>>> providers, 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>>> _______________________________________________<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>> 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/20220912/a8f3ff9e/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 11<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>