Enable libraries to moderate OPAC self-registrations
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-no... *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
Hi Alex, Overall, I like the idea of moderating OPAC self-registrations. Locally, we customize the self-registration to add a restriction to new borrowers, and email the library that there is a pending self-registration. But I think you make a good point about the accessing of electronic content. At a glance, it doesn’t look like you could use the borrower_modifications table at present since it requires a borrowernumber. Maybe one option would be to create the OPAC patron account but without a cardnumber, userid, or password (which you could then provide via borrower_modifications)? I suppose though that user could still be found by some APIs and that might still let them get too far. It looks like borrower_modifications is missing an autonumber primary key… that could be added and then borrowernumber could potentially be made nullable? If you don’t alter borrower_modifications, then you probably need a new table. I wonder about a generic “pending_action” table that incorporated a lot of the tracking of “suggestions”, and then a linking table of “pending_action_borrower_registrations”, and then a table of “borrower_registrations”. (In theory, eventually “suggestions” and “borrower_modifications” could be refactored to hook into this more generic system, and pave the way for easily adding other “pending actions” that need to be moderated. In fact… I think there is a moderation/review process for “reviews” (also known as Comments I think?)… “problem_reports” could’ve benefitted from that too. Hypothetically even “tags_approval”. That’s all a bit grand though. I’d be interested in testing whatever you come up with in any case. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of Alex Buckley Sent: Tuesday, 30 August 2022 8:46 AM To: koha-devel@lists.koha-community.org Subject: [Koha-devel] Enable libraries to moderate OPAC self-registrations 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-no... 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
Hi David, Thanks very much for your reply. I'm glad you like the idea of moderating OPAC self-registrations. Yes, as you say we could use the borrower_modifications table. Adding an auto-number primary key and making borrower_modifications.borrowernumber nullable. Then when a user self registered a row is added to the borrower_modifications table with a null borrowernumber, and no cardnumber, userid and password. If approved the row could be shifted to the borrowers table with a borrowernumber, cardnumber, userid set. The password could be set by the new borrower via the password reset link emailed to them. I'm not sure if it is 'cleaner' to re-work the existing borrower_modifications table or make a new database table. I might try out with both locally and see how it goes, unless anyone else has strong opinions on this? A generic pending_action table sounds like a great long term goal for sure! I think for bug 25090 if I do go with a new table it would only be for OPAC self registrations though. Thanks again for your thoughts and yes if you would be happy to test once it is ready that would be amazing! Kind regards, Alex On 30/08/22 16:22, dcook@prosentient.com.au wrote:
Hi Alex,
Overall, I like the idea of moderating OPAC self-registrations.
Locally, we customize the self-registration to add a restriction to new borrowers, and email the library that there is a pending self-registration. But I think you make a good point about the accessing of electronic content.
At a glance, it doesn’t look like you could use the borrower_modifications table at present since it requires a borrowernumber.
Maybe one option would be to create the OPAC patron account but without a cardnumber, userid, or password (which you could then provide via borrower_modifications)? I suppose though that user could still be found by some APIs and that might still let them get too far. It looks like borrower_modifications is missing an autonumber primary key… that could be added and then borrowernumber could potentially be made nullable?
If you don’t alter borrower_modifications, then you probably need a new table.
I wonder about a generic “pending_action” table that incorporated a lot of the tracking of “suggestions”, and then a linking table of “pending_action_borrower_registrations”, and then a table of “borrower_registrations”. (In theory, eventually “suggestions” and “borrower_modifications” could be refactored to hook into this more generic system, and pave the way for easily adding other “pending actions” that need to be moderated. In fact… I think there is a moderation/review process for “reviews” (also known as Comments I think?)… “problem_reports” could’ve benefitted from that too. Hypothetically even “tags_approval”. That’s all a bit grand though.
I’d be interested in testing whatever you come up with in any case.
David Cook
Senior Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
*From:*Koha-devel <koha-devel-bounces@lists.koha-community.org> *On Behalf Of *Alex Buckley *Sent:* Tuesday, 30 August 2022 8:46 AM *To:* koha-devel@lists.koha-community.org *Subject:* [Koha-devel] Enable libraries to moderate OPAC self-registrations
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-no...
*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
-- 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.
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@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-no... *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/
Thanks for that Tomas, I appreciate it. I will add a separate table(s) and will have a think about what you have noted. Kind regards, Alex On 31/08/22 14: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@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-no...
*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@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.
Hi Alex (&folks) What about the electronic ressources uses the Koha groups/patron_category to allow or deny access to the resource? Then if newly created patrons have a specific default category, then this category could be denied access to electronic resources. We've done this way for our frontend software (Bokeh) and it works quite well. Upon login, the patron category is received. Depending on the category, the user can see the links to electronic resource or not. Also the electronic resource server checks the category against Koha using CAS attributes. Cheers, Arthur On 31/08/2022 06:32, Alex Buckley wrote:
Thanks for that Tomas, I appreciate it. I will add a separate table(s) and will have a think about what you have noted.
Kind regards,
Alex
On 31/08/22 14: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@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-no...
*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@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.
_______________________________________________ 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/
Hi Arthur, Thanks very much for your reply. Very interesting idea! Are the electronic resources that you hide with Bokeh the links in biblio 856$u subfields? To give you some more context, one of the reasons this feature was proposed was that as soon as patrons have a Koha userid and password then they could authenticate (via Stunnel/SIP2) to electronic platforms linked from the OpacNav HTML customisations on the OPAC home page. Meaning if the OPAC has OPACPublic='Enable' then electronic resource platform links in HTML customisations would be visible on the OPAC home page and, therefore, accessible to all users regardless of their patron category. Having some ability for libraries to moderate registrations, before those users have a userid and password, would restrict whether they could authenticate to these electronic platforms via Stunnel/SIP2. Thanks, Alex On 1/09/22 01:01, Arthur wrote:
Hi Alex (&folks)
What about the electronic ressources uses the Koha groups/patron_category to allow or deny access to the resource?
Then if newly created patrons have a specific default category, then this category could be denied access to electronic resources.
We've done this way for our frontend software (Bokeh) and it works quite well. Upon login, the patron category is received.
Depending on the category, the user can see the links to electronic resource or not. Also the electronic resource server checks the category against Koha using CAS attributes.
Cheers,
Arthur
On 31/08/2022 06:32, Alex Buckley wrote:
Thanks for that Tomas, I appreciate it. I will add a separate table(s) and will have a think about what you have noted.
Kind regards,
Alex
On 31/08/22 14: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@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-no...
*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@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.
_______________________________________________ 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 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/
-- 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.
Hi Alex, In our case (Koha + Bokeh + ArteCampus), being able to authenticate against Koha doesn't mean someone would be granted access the resource (permissions are managed by ArteCampus). In our case, any koha user can authenticate and see the link to the resource, even non connected users can see the link. However, ArteCampus reads the patron category upon authentication and only grants access to the resource to some selected categories. ArteCampus uses CASv3 to authenticate against Bokeh (Bokeh gets a copy of koha users once a day). Since Bokeh imports the patron category as a group, and CASv3 exports group information as an attribute upon authentication, ArteCampus can read this information, to check if a user can be granted access to a resource. It is then possible for the librarians who manage ArteCampus to deny access to resource for certain koha categories. This works with ArteCampus because they made some effort into integrating users attributes but I don't know if that would be easily reproducible with any other electronic resource provider, people would need to ask their provider if they have those kind of features, which may not be the case. Maybe you could make something with koha permissions or a syspref so that the default category for self registered users is not able to login to the OPAC (nor the API...) until moved to a proper category by the librarians who validates the registration process? Best, Arthur On 01/09/2022 07:39, Alex Buckley wrote:
Hi Arthur,
Thanks very much for your reply. Very interesting idea!
Are the electronic resources that you hide with Bokeh the links in biblio 856$u subfields?
To give you some more context, one of the reasons this feature was proposed was that as soon as patrons have a Koha userid and password then they could authenticate (via Stunnel/SIP2) to electronic platforms linked from the OpacNav HTML customisations on the OPAC home page.
Meaning if the OPAC has OPACPublic='Enable' then electronic resource platform links in HTML customisations would be visible on the OPAC home page and, therefore, accessible to all users regardless of their patron category.
Having some ability for libraries to moderate registrations, before those users have a userid and password, would restrict whether they could authenticate to these electronic platforms via Stunnel/SIP2.
Thanks,
Alex
On 1/09/22 01:01, Arthur wrote:
Hi Alex (&folks)
What about the electronic ressources uses the Koha groups/patron_category to allow or deny access to the resource?
Then if newly created patrons have a specific default category, then this category could be denied access to electronic resources.
We've done this way for our frontend software (Bokeh) and it works quite well. Upon login, the patron category is received.
Depending on the category, the user can see the links to electronic resource or not. Also the electronic resource server checks the category against Koha using CAS attributes.
Cheers,
Arthur
On 31/08/2022 06:32, Alex Buckley wrote:
Thanks for that Tomas, I appreciate it. I will add a separate table(s) and will have a think about what you have noted.
Kind regards,
Alex
On 31/08/22 14: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@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-no...
*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@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.
_______________________________________________ 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 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/
-- 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.
Hi Arthur, Thanks for your response! It's always interesting to hear other Koha vendors' workflows. I think a combination of what you outline and what David C suggested would work. When a new syspref is enabled then the default category of self-registered users is restricted from logging in via SIP2. Therefore, they can see and click on the links to electronic resources, but not authenticate until a librarian has shifted them to a different patron category. What I will do is write patches for this as the first step. As I mentioned in the email response to David just now I still think adding the ability for librarians to moderate patron accounts in a similar way as is done for patron self-edit requests would be a useful end goal, but upstreaming the above behavior would be a good first step to build on. Many thanks, Alex On 2/09/22 00:53, Arthur wrote:
Hi Alex,
In our case (Koha + Bokeh + ArteCampus), being able to authenticate against Koha doesn't mean someone would be granted access the resource (permissions are managed by ArteCampus).
In our case, any koha user can authenticate and see the link to the resource, even non connected users can see the link.
However, ArteCampus reads the patron category upon authentication and only grants access to the resource to some selected categories.
ArteCampus uses CASv3 to authenticate against Bokeh (Bokeh gets a copy of koha users once a day).
Since Bokeh imports the patron category as a group, and CASv3 exports group information as an attribute upon authentication, ArteCampus can read this information, to check if a user can be granted access to a resource.
It is then possible for the librarians who manage ArteCampus to deny access to resource for certain koha categories.
This works with ArteCampus because they made some effort into integrating users attributes but I don't know if that would be easily reproducible with any other electronic resource provider, people would need to ask their provider if they have those kind of features, which may not be the case.
Maybe you could make something with koha permissions or a syspref so that the default category for self registered users is not able to login to the OPAC (nor the API...) until moved to a proper category by the librarians who validates the registration process?
Best,
Arthur
On 01/09/2022 07:39, Alex Buckley wrote:
Hi Arthur,
Thanks very much for your reply. Very interesting idea!
Are the electronic resources that you hide with Bokeh the links in biblio 856$u subfields?
To give you some more context, one of the reasons this feature was proposed was that as soon as patrons have a Koha userid and password then they could authenticate (via Stunnel/SIP2) to electronic platforms linked from the OpacNav HTML customisations on the OPAC home page.
Meaning if the OPAC has OPACPublic='Enable' then electronic resource platform links in HTML customisations would be visible on the OPAC home page and, therefore, accessible to all users regardless of their patron category.
Having some ability for libraries to moderate registrations, before those users have a userid and password, would restrict whether they could authenticate to these electronic platforms via Stunnel/SIP2.
Thanks,
Alex
On 1/09/22 01:01, Arthur wrote:
Hi Alex (&folks)
What about the electronic ressources uses the Koha groups/patron_category to allow or deny access to the resource?
Then if newly created patrons have a specific default category, then this category could be denied access to electronic resources.
We've done this way for our frontend software (Bokeh) and it works quite well. Upon login, the patron category is received.
Depending on the category, the user can see the links to electronic resource or not. Also the electronic resource server checks the category against Koha using CAS attributes.
Cheers,
Arthur
On 31/08/2022 06:32, Alex Buckley wrote:
Thanks for that Tomas, I appreciate it. I will add a separate table(s) and will have a think about what you have noted.
Kind regards,
Alex
On 31/08/22 14: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@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-no...
*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@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.
_______________________________________________ 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 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/
-- 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.
-- 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.
You know one option would be to add a Restriction/Debarment to the user on self-registration (like we do locally) and then make sure that SIP doesn’t allow login for restricted patrons (I notice that is what we do locally as well). It wouldn’t meet all use cases, but it could work for yours. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of Alex Buckley Sent: Thursday, 1 September 2022 3:40 PM To: Arthur <arthur.suzuki@biblibre.com>; koha-devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Enable libraries to moderate OPAC self-registrations Hi Arthur, Thanks very much for your reply. Very interesting idea! Are the electronic resources that you hide with Bokeh the links in biblio 856$u subfields? To give you some more context, one of the reasons this feature was proposed was that as soon as patrons have a Koha userid and password then they could authenticate (via Stunnel/SIP2) to electronic platforms linked from the OpacNav HTML customisations on the OPAC home page. Meaning if the OPAC has OPACPublic='Enable' then electronic resource platform links in HTML customisations would be visible on the OPAC home page and, therefore, accessible to all users regardless of their patron category. Having some ability for libraries to moderate registrations, before those users have a userid and password, would restrict whether they could authenticate to these electronic platforms via Stunnel/SIP2. Thanks, Alex On 1/09/22 01:01, Arthur wrote: Hi Alex (&folks) What about the electronic ressources uses the Koha groups/patron_category to allow or deny access to the resource? Then if newly created patrons have a specific default category, then this category could be denied access to electronic resources. We've done this way for our frontend software (Bokeh) and it works quite well. Upon login, the patron category is received. Depending on the category, the user can see the links to electronic resource or not. Also the electronic resource server checks the category against Koha using CAS attributes. Cheers, Arthur On 31/08/2022 06:32, Alex Buckley wrote: Thanks for that Tomas, I appreciate it. I will add a separate table(s) and will have a think about what you have noted. Kind regards, Alex On 31/08/22 14: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@catalyst.net.nz <mailto:alexbuckley@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-no... 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 <mailto: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/ -- 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. _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto: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 list Koha-devel@lists.koha-community.org <mailto: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/ -- 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.
Hi David, Thanks for your response. I think what you outline would work for our use case and would be a good first step to be upstreamed also. I feel like adding the functionality of giving librarians the ability to moderate self-registrations could still be a good end goal for Koha - so that the self registration behaviour could be more consistent with OPAC patron self edit request behaviour. Could you please let me know how have you locally configured SIP to not allow login for restricted patrons? Kind regards, Alex On 2/09/22 11:42, dcook@prosentient.com.au wrote:
You know one option would be to add a Restriction/Debarment to the user on self-registration (like we do locally) and then make sure that SIP doesn’t allow login for restricted patrons (I notice that is what we do locally as well).
It wouldn’t meet all use cases, but it could work for yours.
David Cook
Senior Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
*From:*Koha-devel <koha-devel-bounces@lists.koha-community.org> *On Behalf Of *Alex Buckley *Sent:* Thursday, 1 September 2022 3:40 PM *To:* Arthur <arthur.suzuki@biblibre.com>; koha-devel <koha-devel@lists.koha-community.org> *Subject:* Re: [Koha-devel] Enable libraries to moderate OPAC self-registrations
Hi Arthur,
Thanks very much for your reply. Very interesting idea!
Are the electronic resources that you hide with Bokeh the links in biblio 856$u subfields?
To give you some more context, one of the reasons this feature was proposed was that as soon as patrons have a Koha userid and password then they could authenticate (via Stunnel/SIP2) to electronic platforms linked from the OpacNav HTML customisations on the OPAC home page.
Meaning if the OPAC has OPACPublic='Enable' then electronic resource platform links in HTML customisations would be visible on the OPAC home page and, therefore, accessible to all users regardless of their patron category.
Having some ability for libraries to moderate registrations, before those users have a userid and password, would restrict whether they could authenticate to these electronic platforms via Stunnel/SIP2.
Thanks,
Alex
On 1/09/22 01:01, Arthur wrote:
Hi Alex (&folks)
What about the electronic ressources uses the Koha groups/patron_category to allow or deny access to the resource?
Then if newly created patrons have a specific default category, then this category could be denied access to electronic resources.
We've done this way for our frontend software (Bokeh) and it works quite well. Upon login, the patron category is received.
Depending on the category, the user can see the links to electronic resource or not. Also the electronic resource server checks the category against Koha using CAS attributes.
Cheers,
Arthur
On 31/08/2022 06:32, Alex Buckley wrote:
Thanks for that Tomas, I appreciate it. I will add a separate table(s) and will have a think about what you have noted.
Kind regards,
Alex
On 31/08/22 14: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@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-no...
*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/
--
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.
_______________________________________________
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 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/
-- 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.
-- 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.
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@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-no...
*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@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@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/
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@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@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-no... *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-devel@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
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@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@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-no...
*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@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@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@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/
-- 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.
I'm not planning to work on that in a short term. El lun, 12 sept 2022 a las 5:20, Alex Buckley (<alexbuckley@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@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@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-no... *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-devel@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-devel@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
Thanks Tomas! On 13/09/22 00:34, Tomas Cohen Arazi wrote:
I'm not planning to work on that in a short term.
El lun, 12 sept 2022 a las 5:20, Alex Buckley (<alexbuckley@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@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@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-no...
*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@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@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@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/
-- 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
-- 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.
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@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-no...
*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@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@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@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.
participants (5)
-
Alex Buckley -
Arthur -
dcook＠prosentient.com.au -
Katrin Fischer -
Tomas Cohen Arazi