<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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>
</body>
</html>