<!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 7595 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 5<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: Mon, 5 Sep 2022 13:12:50 +1200<br>From: Alex Buckley <alexbuckley@catalyst.net.nz><br>To: Arthur <arthur.suzuki@biblibre.com>, 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: <20d496d7-4b15-2156-ac35-e2b50718fabf@catalyst.net.nz><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi Arthur,<br><br>Thanks for your response! It's always interesting to hear other Koha<br>vendors' workflows.<br><br>I think a combination of what you outline and what David C suggested<br>would work.<br><br>When a new syspref is enabled then the default category of<br>self-registered users is restricted from logging in via SIP2. Therefore,<br>they can see and click on the links to electronic resources, but not<br>authenticate until a librarian has shifted them to a different patron<br>category. <br><br>What I will do is write patches for this as the first step.<br><br>As I mentioned in the email response to David just now I still think<br>adding the ability for librarians to moderate patron accounts in a<br>similar way as is done for patron self-edit requests would be a useful<br>end goal, but upstreaming the above behavior would be a good first step<br>to build on.<br><br>Many thanks,<br><br>Alex<br><br><br>On 2/09/22 00:53, Arthur wrote:<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<br>> login to the OPAC (nor the API...) until moved to a proper category by<br>> the 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<br>>> home 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<br>>>>>> new 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><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/20220905/92eaa9d2/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 5<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>