<!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 7542 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 2<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 (Arthur)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Thu, 1 Sep 2022 14:53:15 +0200<br>From: Arthur <arthur.suzuki@biblibre.com><br>To: Alex Buckley <alexbuckley@catalyst.net.nz>, koha-devel<br> <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] Enable libraries to moderate OPAC<br> self-registrations<br>Message-ID: <4c4653eb-b360-9470-425e-9ed336c76a3e@biblibre.com><br>Content-Type: text/plain; charset="utf-8"; Format="flowed"<br><br>Hi Alex,<br><br>In our case (Koha + Bokeh + ArteCampus), being able to authenticate <br>against Koha doesn't mean someone would be granted access the resource <br>(permissions are managed by ArteCampus).<br><br>In our case, any koha user can authenticate and see the link to the <br>resource, even non connected users can see the link.<br><br>However, ArteCampus reads the patron category upon authentication and <br>only grants access to the resource to some selected categories.<br><br>ArteCampus uses CASv3 to authenticate against Bokeh (Bokeh gets a copy <br>of koha users once a day).<br><br>Since Bokeh imports the patron category as a group, and CASv3 exports <br>group information as an attribute upon authentication, ArteCampus can <br>read this information, to check if a user can be granted access to a <br>resource.<br><br>It is then possible for the librarians who manage ArteCampus to deny <br>access to resource for certain koha categories.<br><br>This works with ArteCampus because they made some effort into <br>integrating users attributes but I don't know if that would be easily <br>reproducible with any other electronic resource provider, people would <br>need to ask their provider if they have those kind of features, which <br>may not be the case.<br><br><br>Maybe you could make something with koha permissions or a syspref so <br>that the default category for self registered users is not able to login <br>to the OPAC (nor the API...) until moved to a proper category by the <br>librarians who validates the registration process?<br><br>Best,<br><br>Arthur<br><br>On 01/09/2022 07:39, Alex Buckley wrote:<br>><br>> Hi Arthur,<br>><br>> Thanks very much for your reply. Very interesting idea!<br>><br>> Are the electronic resources that you hide with Bokeh the links in <br>> biblio 856$u subfields?<br>><br>> To give you some more context, one of the reasons this feature was <br>> proposed was that as soon as patrons have a Koha userid and password <br>> then they could authenticate (via Stunnel/SIP2) to electronic <br>> platforms linked from the OpacNav HTML customisations on the OPAC home <br>> page.<br>><br>> Meaning if the OPAC has OPACPublic='Enable' then electronic resource <br>> platform links in HTML customisations would be visible on the OPAC <br>> home page and, therefore, accessible to all users regardless of their <br>> patron category.<br>><br>> Having some ability for libraries to moderate registrations, before <br>> those users have a userid and password, would restrict whether they <br>> could authenticate to these electronic platforms via Stunnel/SIP2.<br>><br>> Thanks,<br>><br>> Alex<br>><br>><br>> On 1/09/22 01:01, Arthur wrote:<br>>><br>>> Hi Alex (&folks)<br>>><br>>> What about the electronic ressources uses the Koha <br>>> groups/patron_category to allow or deny access to the resource?<br>>><br>>> Then if newly created patrons have a specific default category, then <br>>> this category could be denied access to electronic resources.<br>>><br>>> We've done this way for our frontend software (Bokeh) and it works <br>>> quite well. Upon login, the patron category is received.<br>>><br>>> Depending on the category, the user can see the links to electronic <br>>> resource or not. Also the electronic resource server checks the <br>>> category against Koha using CAS attributes.<br>>><br>>> Cheers,<br>>><br>>> Arthur<br>>><br>>> On 31/08/2022 06:32, Alex Buckley wrote:<br>>>><br>>>> Thanks for that Tomas, I appreciate it. I will add a separate <br>>>> table(s) 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 <br>>>>> at 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 <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 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<br>>>>> Koha patron account is not created immediately - i.e. they<br>>>>> cannot yet log into the OPAC.<br>>>>><br>>>>> Step 3: A pending registration link appears at the bottom of<br>>>>> the 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,<br>>>>> containing 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<br>>>>> for a library OPAC login and accessing electronic content from<br>>>>> some 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<br>>>>> 3rd party databases were coming from acceptable locations i.e.<br>>>>> they 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>>>><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>> 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/20220901/55a8870b/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 2<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>