[Koha-devel] Enable libraries to moderate OPAC self-registrations
Alex Buckley
alexbuckley at catalyst.net.nz
Mon Sep 12 10:20:40 CEST 2022
Hi Katrin,
Thanks so much for your response. Glad to hear you thought this would be
a useful feature :)
Thanks also for clarifying the use of the borrowernumber in the
borrower_modifications table.
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.
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?
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?
Kind regards,
Alex
On 7/09/22 02:42, Katrin Fischer wrote:
>
> Hi all,
>
> I think the feature would be useful. :)
>
> 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:
>
> * Patron data modification requests from the OPAC (borrowernumber of
> patron)
>
> * Patron self registrations with required email verification
> (borrowernumber = 0)
>
> 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.
>
> Hope this helps,
>
> Katrin
>
> On 31.08.22 04:35, Tomas Cohen Arazi wrote:
>> 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.
>>
>> Moderation should be traceable, etc.
>>
>> Thinking of API routes for the process usually clears the design
>> issues as it points to the classes you will need.
>>
>> El lun, 29 ago 2022 19:46, Alex Buckley <alexbuckley at catalyst.net.nz>
>> escribió:
>>
>> Kia ora/Hello Koha community,
>>
>> I am currently working on reviving bug 25090
>> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25090>
>> ( Moderate OPAC self-registrations before a patron account is
>> created ).
>>
>> *New proposed functionality:*
>>
>> Step 1: The library enables both the new
>> 'PatronSelfRegistrationModeration' syspref and the existing
>> 'OpacResetPassword'syspref.
>>
>> 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.
>>
>> 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).
>>
>> Step 4: Librarians can click on the link to go to a page to
>> approve or decline the registration.
>>
>> Step 4a: If approved the user is sent an email notice, containing
>> their Koha username and an OPAC reset password link.
>>
>> Step 4b: If declined the user is sent a different email notice.
>>
>> *The rationale for adding this feature:*
>> You can currently limit the circulation of self-registered
>> patrons - by using the PatronSelfRegistrationDefaultCategory
>> syspref and creating circulation rule(s) for that category.
>>
>> 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.
>>
>> 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.
>>
>> More details can be found here:
>> https://www.catalyst.net.nz/blog/mental-health-education-resource-library-now-offers-online-self-registration
>>
>> *Questions I would like to hear your thoughts on please:*
>>
>> Q1: Are you in favour of this as a new feature in Koha?
>>
>> 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?
>>
>> Q3: How would you envisage this self-registration moderation
>> feature fitting in with the existing
>> PatronSelfRegistrationVerifyByEmailand
>> PatronSelfRegistrationDefaultCategory sysprefs?
>>
>> Any thoughts much appreciated.
>>
>> Kind regards,
>>
>> Alex
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : https://www.koha-community.org/
>> git : https://git.koha-community.org/
>> bugs : https://bugs.koha-community.org/
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : https://www.koha-community.org/
>> git : https://git.koha-community.org/
>> bugs : https://bugs.koha-community.org/
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : https://www.koha-community.org/
> git : https://git.koha-community.org/
> bugs : https://bugs.koha-community.org/
--
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220912/a8f3ff9e/attachment-0001.htm>
More information about the Koha-devel
mailing list