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 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/
