I'm not planning to work on that in a short term. El lun, 12 sept 2022 a las 5:20, Alex Buckley (<alexbuck...@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...@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 <alexbuck...@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@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-de...@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@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-de...@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
_______________________________________________ Koha-devel mailing list Koha-devel@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/
