<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Arthur, <br>
</p>
<p>Thanks for your response! It's always interesting to hear other
Koha vendors' workflows. <br>
</p>
<p>I think a combination of what you outline and what David C
suggested would work. <br>
</p>
<p>When a new syspref is enabled then the default category of
self-registered users is restricted from logging in via SIP2.
Therefore, they can see and click on the links to electronic
resources, but not authenticate until a librarian has shifted them
to a different patron category. </p>
<p>What I will do is write patches for this as the first step.</p>
<p>As I mentioned in the email response to David just now I still
think adding the ability for librarians to moderate patron
accounts in a similar way as is done for patron self-edit requests
would be a useful end goal, but upstreaming the above behavior
would be a good first step to build on. <br>
</p>
<p>Many thanks,</p>
<p>Alex</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 2/09/22 00:53, Arthur wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4c4653eb-b360-9470-425e-9ed336c76a3e@biblibre.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi Alex,</p>
<p>In our case (Koha + Bokeh + ArteCampus), being able to
authenticate against Koha doesn't mean someone would be granted
access the resource (permissions are managed by ArteCampus).</p>
<p>In our case, any koha user can authenticate and see the link to
the resource, even non connected users can see the link.</p>
<p>However, ArteCampus reads the patron category upon
authentication and only grants access to the resource to some
selected categories.</p>
<p>ArteCampus uses CASv3 to authenticate against Bokeh (Bokeh gets
a copy of koha users once a day).</p>
<p>Since Bokeh imports the patron category as a group, and CASv3
exports group information as an attribute upon authentication,
ArteCampus can read this information, to check if a user can be
granted access to a resource.</p>
<p>It is then possible for the librarians who manage ArteCampus to
deny access to resource for certain koha categories.</p>
<p>This works with ArteCampus because they made some effort into
integrating users attributes but I don't know if that would be
easily reproducible with any other electronic resource provider,
people would need to ask their provider if they have those kind
of features, which may not be the case.</p>
<p><br>
</p>
<p>Maybe you could make something with koha permissions or a
syspref so that the default category for self registered users
is not able to login to the OPAC (nor the API...) until moved to
a proper category by the librarians who validates the
registration process?<br>
</p>
<p>Best,</p>
<p>Arthur</p>
<div class="moz-cite-prefix">On 01/09/2022 07:39, Alex Buckley
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:84a5b948-29dd-599f-5f07-692d496f1b19@catalyst.net.nz">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>Hi Arthur, <br>
</p>
<p>Thanks very much for your reply. Very interesting idea!<br>
</p>
<p>Are the electronic resources that you hide with Bokeh the
links in biblio 856$u subfields? <br>
</p>
<p>To give you some more context, one of the reasons this
feature was proposed was that as soon as patrons have a Koha
userid and password then they could authenticate (via
Stunnel/SIP2) to electronic platforms linked from the OpacNav
HTML customisations on the OPAC home page.</p>
<p>Meaning if the OPAC has OPACPublic='Enable' then electronic
resource platform links in HTML customisations would be
visible on the OPAC home page and, therefore, accessible to
all users regardless of their patron category.<br>
</p>
<p>Having some ability for libraries to moderate registrations,
before those users have a userid and password, would restrict
whether they could authenticate to these electronic platforms
via Stunnel/SIP2.</p>
<p>Thanks,</p>
<p>Alex</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 1/09/22 01:01, Arthur wrote:<br>
</div>
<blockquote type="cite"
cite="mid:a5a23b3b-e50e-ee63-79a0-5a9781baa158@biblibre.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>Hi Alex (&folks)<br>
</p>
<p>What about the electronic ressources uses the Koha
groups/patron_category to allow or deny access to the
resource?</p>
<p>Then if newly created patrons have a specific default
category, then this category could be denied access to
electronic resources.</p>
<p>We've done this way for our frontend software (Bokeh) and
it works quite well. Upon login, the patron category is
received.</p>
<p>Depending on the category, the user can see the links to
electronic resource or not. Also the electronic resource
server checks the category against Koha using CAS
attributes.<br>
</p>
<p>Cheers,</p>
<p>Arthur<br>
</p>
<div class="moz-cite-prefix">On 31/08/2022 06:32, Alex Buckley
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:7d13ac6a-6fec-9526-a514-d1aece591f22@catalyst.net.nz">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>Thanks for that Tomas, I appreciate it. I will add a
separate table(s) and will have a think about what you
have noted.</p>
<p>Kind regards,</p>
<p>Alex<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 31/08/22 14:35, Tomas Cohen
Arazi wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CABZfb=U7XMt4d3Mf1Vh1Fgm_iuGboUYd62icxbZLn1jqEjfHBw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div dir="auto">Please, use a separate table. And think of
the request workflow handling in the db, the statuses
(as enum), how it will be handled at library or library
group level. Even if not implemented at this stage.
Also, maybe you need more than one table, don't fear
adding tables if they make sense and give us a cleaner
implementation.
<div dir="auto"><br>
</div>
<div dir="auto">Moderation should be traceable, etc.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Thinking of API routes for the process
usually clears the design issues as it points to the
classes you will need.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">El lun, 29 ago 2022
19:46, Alex Buckley <<a
href="mailto:alexbuckley@catalyst.net.nz"
moz-do-not-send="true" class="moz-txt-link-freetext">alexbuckley@catalyst.net.nz</a>>
escribió:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<p>Kia ora/Hello Koha community, <br>
</p>
<p>I am currently working on reviving <a
href="https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25090"
target="_blank" rel="noreferrer"
moz-do-not-send="true">bug 25090</a> ( <span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display">Moderate OPAC
self-registrations before a patron account is
created ).</span></span></p>
<p><b>New proposed functionality:</b><br>
</p>
<p><span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display">Step 1: The
library enables both the new
'PatronSelfRegistrationModeration' syspref and
the existing 'OpacResetPassword'</span></span><span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display"><span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display"> syspref.<br>
</span></span></span></span></p>
<p><span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display">Step 2: When a
user submits an OPAC self-registration their
Koha patron account is not created immediately
- i.e. they cannot yet log into the OPAC.<br>
</span></span></p>
<p><span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display">Step 3: A pending
registration link appears at the bottom of the
staff client home page (like what's currently
done with new purchase suggestions, or OPAC
patron modification requests). <br>
</span></span></p>
<p><span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display">Step 4: Librarians
can click on the link to go to a page to
approve or decline the registration.</span></span></p>
<p><span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display">Step 4a: If
approved the user is sent an email notice,
containing their Koha username and an OPAC
reset password link.<br>
</span></span></p>
<p><span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display">Step 4b: If
declined the user is sent a different email
notice.<br>
</span></span></p>
<p><b><span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display">The rationale for
adding this feature:</span></span></b><br>
<span id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display">You can currently
limit the circulation of self-registered
patrons - by using the
PatronSelfRegistrationDefaultCategory syspref
and creating circulation rule(s) for that
category.<br>
</span></span></p>
<p><span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display">However, users
only need an OPAC login (without the ability
to circulate) to access electronic content
providers (integrated with Koha via
STunnel/SIP2). Some electronic content
providers charge libraries based on their
usage. Meaning it might not be optimal having
anyone from around the world self-registering
for a library OPAC login and accessing
electronic content from some providers,
therefore, incurring extra costs for the
library.<br>
</span></span></p>
<p><span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display">Bug 25090 was
originally developed in the early days of the
pandemic to ensure new self-registering OPAC
users accessing 3rd party databases were
coming from acceptable locations i.e. they
were members of the organisation the library
is in.<br>
</span></span></p>
<p><span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display">More details can
be found here: <a
href="https://www.catalyst.net.nz/blog/mental-health-education-resource-library-now-offers-online-self-registration"
target="_blank" rel="noreferrer"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.catalyst.net.nz/blog/mental-health-education-resource-library-now-offers-online-self-registration</a><br>
</span></span></p>
<b>Questions I would like to hear your thoughts on
please:</b>
<p><span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display">Q1: Are you in
favour of this as a new feature in Koha?<br>
</span></span></p>
<p><span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display">Q2: Would you
prefer a new database table be added for
self-registrations awaiting approval, or
should I use the borrowers_modifications table
- as is used by OPAC patron modification
requests?</span></span></p>
<p><span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display">Q3: How would you
envisage this self-registration moderation
feature fitting in with the existing
PatronSelfRegistrationVerifyByEmail</span></span><span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display"> and </span></span><span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display">PatronSelfRegistrationDefaultCategory
sysprefs?</span></span></p>
<p><span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display">Any thoughts much
appreciated.</span></span></p>
<p><span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display">Kind regards,<br>
</span></span></p>
<p><span
id="m_-3636630875619344738summary_container"><span
id="m_-3636630875619344738short_desc_nonedit_display">Alex<br>
</span></span></p>
</div>
_______________________________________________<br>
Koha-devel mailing list<br>
<a href="mailto:Koha-devel@lists.koha-community.org"
target="_blank" rel="noreferrer"
moz-do-not-send="true" class="moz-txt-link-freetext">Koha-devel@lists.koha-community.org</a><br>
<a
href="https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a><br>
website : <a href="https://www.koha-community.org/"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://www.koha-community.org/</a><br>
git : <a href="https://git.koha-community.org/"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://git.koha-community.org/</a><br>
bugs : <a href="https://bugs.koha-community.org/"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.koha-community.org/</a><br>
</blockquote>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Alex Buckley
Koha Developer | Implementation Lead
Catalyst IT - Expert Open Source Solutions
Catalyst.Net Ltd - a Catalyst IT group company
CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.
It may contain privileged, confidential or copyright information. If you are not
the named recipient, any use, reliance upon, disclosure or copying of this email
or its attachments is unauthorised. If you have received this email in error,
please reply via email or call +64 4 499 2267.</pre>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Koha-devel mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:Koha-devel@lists.koha-community.org" moz-do-not-send="true">Koha-devel@lists.koha-community.org</a>
<a class="moz-txt-link-freetext" href="https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" moz-do-not-send="true">https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a>
website : <a class="moz-txt-link-freetext" href="https://www.koha-community.org/" moz-do-not-send="true">https://www.koha-community.org/</a>
git : <a class="moz-txt-link-freetext" href="https://git.koha-community.org/" moz-do-not-send="true">https://git.koha-community.org/</a>
bugs : <a class="moz-txt-link-freetext" href="https://bugs.koha-community.org/" moz-do-not-send="true">https://bugs.koha-community.org/</a>
</pre>
</blockquote>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Koha-devel mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:Koha-devel@lists.koha-community.org" moz-do-not-send="true">Koha-devel@lists.koha-community.org</a>
<a class="moz-txt-link-freetext" href="https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" moz-do-not-send="true">https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a>
website : <a class="moz-txt-link-freetext" href="https://www.koha-community.org/" moz-do-not-send="true">https://www.koha-community.org/</a>
git : <a class="moz-txt-link-freetext" href="https://git.koha-community.org/" moz-do-not-send="true">https://git.koha-community.org/</a>
bugs : <a class="moz-txt-link-freetext" href="https://bugs.koha-community.org/" moz-do-not-send="true">https://bugs.koha-community.org/</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Alex Buckley
Koha Developer | Implementation Lead
Catalyst IT - Expert Open Source Solutions
Catalyst.Net Ltd - a Catalyst IT group company
CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.
It may contain privileged, confidential or copyright information. If you are not
the named recipient, any use, reliance upon, disclosure or copying of this email
or its attachments is unauthorised. If you have received this email in error,
please reply via email or call +64 4 499 2267.</pre>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">--
Alex Buckley
Koha Developer | Implementation Lead
Catalyst IT - Expert Open Source Solutions
Catalyst.Net Ltd - a Catalyst IT group company
CONFIDENTIALITY NOTICE: This email is intended for the named recipients only.
It may contain privileged, confidential or copyright information. If you are not
the named recipient, any use, reliance upon, disclosure or copying of this email
or its attachments is unauthorised. If you have received this email in error,
please reply via email or call +64 4 499 2267.</pre>
</body>
</html>