<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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" href="mailto:Koha-devel@lists.koha-community.org">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">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/">https://www.koha-community.org/</a>
git : <a class="moz-txt-link-freetext" href="https://git.koha-community.org/">https://git.koha-community.org/</a>
bugs : <a class="moz-txt-link-freetext" href="https://bugs.koha-community.org/">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>
</body>
</html>