<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Katrin, <br>
</p>
<p>Thanks so much for your response. Glad to hear you thought this
would be a useful feature :)<br>
</p>
<p>Thanks also for clarifying the use of the borrowernumber in the
borrower_modifications table.<br>
</p>
<p>I agree with Tomas in regards to having a new table(s) would make
for a cleaner implementation, but then you raise a good point
about how a new table could need to have a similar structure to
borrowers, deletedborrowers and borrowers_modifications. <br>
</p>
<p>Would it be considered problematic from a QA point of view to add
a new table that will have to be kept in sync every time new
columns are added to the borrowers table?</p>
<p>My thoughts regarding how data could flow when email verification
is used, in addition to moderation, were that after a patron
registration was approved it was only shifted to the borrowers
table when the email is verified - essentially keeping some of the
current workflow. But happy to do otherwise if you have anything
in mind here?<br>
</p>
<p>Kind regards,</p>
<p>Alex<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 7/09/22 02:42, Katrin Fischer wrote:<br>
</div>
<blockquote type="cite"
cite="mid:9741b057-4026-b2bf-d7d1-95f96f12e084@web.de">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi all,</p>
<p>I think the feature would be useful. :)<br>
</p>
<p>I feel there has been some misunderstanding about the
borrower_modifications table. It doesn't require a valid
borrowernumber as the table is used for at least 2 purposes
already:</p>
<p>* Patron data modification requests from the OPAC
(borrowernumber of patron)<br>
</p>
<p>* Patron self registrations with required email verification
(borrowernumber = 0)<br>
</p>
<p>It's used as a temporary storage for patron data and I am not
sure if a separate table would makes sense as the table
structure would probably be really similar. We already need to
keep 3 tables in sync when adding columns: borrowers,
deletedborrowers, borrower_modifications. We might also want to
think about how the data will move when email verification is
used in addition to moderation. <br>
</p>
<p>Hope this helps,</p>
<p>Katrin<br>
</p>
<div class="moz-cite-prefix">On 31.08.22 04: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>
<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>