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