[Koha-devel] Enable libraries to moderate OPAC self-registrations

Mon Sep 12 14:34:50 CEST 2022

I'm not planning to work on that in a short term.

El lun, 12 sept 2022 a las 5:20, Alex Buckley (<alexbuckley at catalyst.net.nz>)
escribió:

> Good point Tomas.
>
> An unmoderated patron registration would be like a staged (but not
> imported) patron record.
>
> I see you created a bug report for that functionality on
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20916
>
> Were you planning on working on that or is it available for others to work
> on it?
>
>
> On 7/09/22 03:04, Tomas Cohen Arazi wrote:
>
> I think we need to resurrect the idea of a patron import staging + import
> step. This one being a particular use case.
>
> El mar, 6 sept 2022 a las 7:43, Katrin Fischer (<katrin.fischer.83 at web.de>)
> escribió:
>
>> 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  PatronSelfRegistrationVerifyByEmail and 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 listKoha-devel at lists.koha-community.orghttps://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/
>>
>
>
> --
> Tomás Cohen Arazi
> Theke Solutions (http://theke.io)
> ✆ +54 9351 3513384
> GPG: B2F3C15F
>
> _______________________________________________
> Koha-devel mailing listKoha-devel at lists.koha-community.orghttps://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.
>
>

-- 
Tomás Cohen Arazi
Theke Solutions (http://theke.io)
✆ +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220912/0dfc49f5/attachment.htm>