|
Description
Pedro Amorim
2024-02-28 16:44:38 UTC
This is ready for testing. Branch at: https://github.com/PTFS-Europe/koha/commits/b_36197 0) If k-t-d, run updatedatabase (ignore this if testing on a sandbox) 1) Enable ILLModule syspref: {staff_url}/cgi-bin/koha/admin/preferences.pl?tab=&op=search&searchfield=ILLModule 2) No need to install a backend as 35570 is in the tree 3) On a different browser session, without being lgoged in, access the create ILL request OPAC page directly: {opac_url}/cgi-bin/koha/opac-illrequests.pl?method=create&backend=Standard 4) Notice you're presented with the login page, as expected 5) Enable ILLOpacUnauthenticatedRequest: {staff_url}/cgi-bin/koha/admin/preferences.pl?tab=&op=search&searchfield=ILLOpacUnauthenticatedRequest 6) Repeat step 3) Notice you now get the create ILL request form, with some additional inputs at the top specific to an unauthenticated request (first name, last name, e-mail address) 6.5) (optional) Confirm the 'Make an Interlibrary loan request' link exists at the bottom of the search results page, while unauthenticated on OPAC: {opac_url}/cgi-bin/koha/opac-search.pl?idx=&q=music&weight_search=1 This should only show for authenticated OPAC users if ILLOpacUnauthenticatedRequest is off. 7) Test the form, try submitting with some blank fields, change type and library after and before inputing data in the input fields, etc. 8) Submit the form successfully. Notice you're presented with the unauthenticated request submission confirmation screen with a message and request details. 9) Go back to Staff UI, logged in, access ILL requests and confirm the unauthenticated request submitted through the OPAC is there: {staff_url}/cgi-bin/koha/ill/ill-requests.pl 10) Test that you can add a patron afterwards, if needed, by clicking 'Edit request' on the toolbar of the manage request page, and entering a patron ID 11) Test that you're able to 'confirm' the request by clicking 'Confirm request', as if it was a regular 'NEW' request. Additional testing: Make sure existing ILL functionality interacts with this new optional workflow behavior. For this, we're using ILLModuleDisclaimerByType. ILLCheckAvailability or AutoILLBackendPriority can also be used but require more setup (plugins, credentials, etc) 1) Configure ILLModuleDisclaimerByType, visit {staff_url}/cgi-bin/koha/admin/preferences.pl?tab=&op=search&searchfield=ILLModuleDisclaimerByType 2) Click the 'edit' link at the bottom of the syspref and copy the example code from the description into the text box. Save. 3) Repeat the original test plan from above, but make sure the request type is not 'article' (as that type is bypassed). Use 'journal', for example. Submit the request making sure you fill in all mandatory fields. 4) Notice you're now presented with the ILL request disclaimer screen, hit Submit. Notice the request is created as before. 5) Return to Staff UI, logged in, confirm this 2nd unauthenticated request has been created and the type disclaimer info is stored and presented when viewing the request. Run tests (k-t-d only): prove t/db_dependent/Koha/ILL/Backends.t prove t/db_dependent/selenium/opac_ill_requests.t prove t/lib/plugins/Koha/Plugin/ILL/TestPlugin.pm Sponsored-by: NHS England (National Health Service England) This is ready for testing. Branch at: https://github.com/PTFS-Europe/koha/commits/b_36197 0) If k-t-d, run updatedatabase (ignore this if testing on a sandbox) 1) Enable ILLModule syspref: {staff_url}/cgi-bin/koha/admin/preferences.pl?tab=&op=search&searchfield=ILLModule 2) No need to install a backend as 35570 is in the tree 3) On a different browser session, without being lgoged in, access the create ILL request OPAC page directly: {opac_url}/cgi-bin/koha/opac-illrequests.pl?method=create&backend=Standard 4) Notice you're presented with the login page, as expected 5) Enable ILLOpacUnauthenticatedRequest: {staff_url}/cgi-bin/koha/admin/preferences.pl?tab=&op=search&searchfield=ILLOpacUnauthenticatedRequest 6) Repeat step 3) Notice you now get the create ILL request form, with some additional inputs at the top specific to an unauthenticated request (first name, last name, e-mail address) 6.5) (optional) Confirm the 'Make an Interlibrary loan request' link exists at the bottom of the search results page, while unauthenticated on OPAC: {opac_url}/cgi-bin/koha/opac-search.pl?idx=&q=music&weight_search=1 This should only show for authenticated OPAC users if ILLOpacUnauthenticatedRequest is off. 7) Test the form, try submitting with some blank fields, change type and library after and before inputing data in the input fields, etc. 8) Submit the form successfully. Notice you're presented with the unauthenticated request submission confirmation screen with a message and request details. 9) Go back to Staff UI, logged in, access ILL requests and confirm the unauthenticated request submitted through the OPAC is there: {staff_url}/cgi-bin/koha/ill/ill-requests.pl 10) Test that you can add a patron afterwards, if needed, by clicking 'Edit request' on the toolbar of the manage request page, and entering a patron ID 11) Test that you're able to 'confirm' the request by clicking 'Confirm request', as if it was a regular 'NEW' request. Additional testing: Make sure existing ILL functionality interacts with this new optional workflow behavior. For this, we're using ILLModuleDisclaimerByType. ILLCheckAvailability or AutoILLBackendPriority can also be used but require more setup (plugins, credentials, etc) 1) Configure ILLModuleDisclaimerByType, visit {staff_url}/cgi-bin/koha/admin/preferences.pl?tab=&op=search&searchfield=ILLModuleDisclaimerByType 2) Click the 'edit' link at the bottom of the syspref and copy the example code from the description into the text box. Save. 3) Repeat the original test plan from above, but make sure the request type is not 'article' (as that type is bypassed). Use 'journal', for example. Submit the request making sure you fill in all mandatory fields. 4) Notice you're now presented with the ILL request disclaimer screen, hit Submit. Notice the request is created as before. 5) Return to Staff UI, logged in, confirm this 2nd unauthenticated request has been created and the type disclaimer info is stored and presented when viewing the request. Run tests (k-t-d only): prove t/db_dependent/Koha/ILL/Backends.t prove t/db_dependent/selenium/opac_ill_requests.t Sponsored-by: NHS England (National Health Service England) I had a go at testing. I haven't signed off yet, mainly because of the error noted in note 5.
Notes from testing (using KTD):
1. Step 8: When you submit the request for type 'Book' (when unauthenticated) and visit the link, you go to a newly created record. This is discoverable by searching. None of the other types creates a record.
2. Additional testing - step 3: I only tested with ILLModuleDisclaimerByType. I don't get a type of 'article', but I think that is the code for 'Journal article'? I get Book, Chapter, Journal, Journal article, Thesis, Conference, DVD, Other, Generic resource.
3. On the input form, compulsory fields have an asterisk after the field label, but nothing to say that these are mandatory (that is, an explanation for the *). When you submit without completing a mandatory field, a plain text message appears at the top. This is different from the "normal" way of presenting forms in the OPAC, but I think you are aware of that 8-).
4. Before or after submitting the form when unauthenticated, the breadcrumb link ('Interlibrary loan requests') comes up with the 'Login to your account' form.
5. If request type is DVD, I get an error trace:
Template process failed: file error - /kohadevbox/koha/Koha/ILL/Backend/shared-includes/forms/dvd.inc: not found at /kohadevbox/koha/C4/Templates.pm line 134
in C4::Templates::output at /kohadevbox/koha/C4/Templates.pm line 134
....
6. If the request type is Other, there are no additional fields to complete (you can add custom fields).
7. Tests pass. Note: need to start up KTD with Selenium (ktd --selenium up).
Hi David, great testing as usual thank you so much. 1) Good point. This is default behavior (for book type) that precedes this work. I'm open to suggestions but have kept this unchanged for now. 2) Correct, 'article' is the code for 'Journal article' 3) Fair points about the form / required fields. As before, I'm open to suggestions but this is default behavior that precedes this work so I've not addressed this here. 4) Thanks for this, will look for providing a follow-up for it. 5) The DVD error, I believe is unrelated to this development and comes from the original commit that added it: https://github.com/PTFS-Europe/koha-ill-freeform/commit/9d735a2dce267d67b4396a0a33d7cb9521a1dfbe I believe a required shared-includes/forms/dvd.inc is missing here. I've added Lucas in case he wishes/is available to provide a follow-up here. 6) For the 'other' request type, having no input fields is expected I believe as there's no way what 'other' would have as input hence only considering the custom fields. (In reply to Pedro Amorim from comment #4) > Hi David, great testing as usual thank you so much. > 1) Good point. This is default behavior (for book type) that precedes this > work. I'm open to suggestions but have kept this unchanged for now. > 2) Correct, 'article' is the code for 'Journal article' > 3) Fair points about the form / required fields. As before, I'm open to > suggestions but this is default behavior that precedes this work so I've not > addressed this here. > 4) Thanks for this, will look for providing a follow-up for it. > 5) The DVD error, I believe is unrelated to this development and comes from > the original commit that added it: > https://github.com/PTFS-Europe/koha-ill-freeform/commit/ > 9d735a2dce267d67b4396a0a33d7cb9521a1dfbe > I believe a required shared-includes/forms/dvd.inc is missing here. I've > added Lucas in case he wishes/is available to provide a follow-up here. > 6) For the 'other' request type, having no input fields is expected I > believe as there's no way what 'other' would have as input hence only > considering the custom fields. Thanks Pedro! Please add my sign off to the bug. Signed-off-by: David Nind <david@davidnind.com> Created attachment 171358 [details] [review] Bug 36197: Add ILLOpacUnauthenticatedRequest sys pref Signed-off-by: David Nind <david@davidnind.com> Created attachment 171359 [details] [review] Bug 36197: Add opac_unauthenticated_ill_requests backend capability to 'Standard' backend Signed-off-by: David Nind <david@davidnind.com> Created attachment 171360 [details] [review] Bug 36197: Consider unauthenticated_ill in 'Standard' create form This also makes sure an empty left side bar exists for opac unauthenticated screens Signed-off-by: David Nind <david@davidnind.com> Created attachment 171361 [details] [review] Bug 36197: Refactor -> opac_available_backends method Signed-off-by: David Nind <david@davidnind.com> Created attachment 171362 [details] [review] Bug 36197: Add UNAUTH Standard request status Assign this new UNAUTH status for unauthenticated requests Signed-off-by: David Nind <david@davidnind.com> Created attachment 171363 [details] [review] Bug 36197: Update how form params are validated Validating an unauth request form requires checking for unauth info fields. Validating a regular authenticated request requires checking for borrower information. Signed-off-by: David Nind <david@davidnind.com> Created attachment 171364 [details] [review] Bug 36197: Update how the request is added: - Do not validate borrower if its an unauthenticated request - Set borrowernumber to null if its an unauthenticated request - Add staff and OPAC notes with unauthenticated request info Signed-off-by: David Nind <david@davidnind.com> Created attachment 171365 [details] [review] Bug 36197: Only check limits for regular requests Skip for unauthenticated requests Signed-off-by: David Nind <david@davidnind.com> Created attachment 171366 [details] [review] Bug 36197: OPAC unauthenticated screen unauth_view to show request details after its been submitted Signed-off-by: David Nind <david@davidnind.com> Created attachment 171367 [details] [review] Bug 36197: Make authentication not required if conditions are met /cgi-bin/koha/opac-illrequests.pl was an authrequired page Now, its authnotrequired if creating or viewing an unauthenticated request Signed-off-by: David Nind <david@davidnind.com> Created attachment 171368 [details] [review] Bug 36197: Unauthenticated patron can always place ILL request if ILLOpacUnauthenticatedRequest Signed-off-by: David Nind <david@davidnind.com> Created attachment 171369 [details] [review] Bug 36197: Only add cardnumber info to request is a user is logged in Signed-off-by: David Nind <david@davidnind.com> Created attachment 171370 [details] [review] Bug 36197: OPAC 'Make an ILL request' link Show the 'Make an ILL request' link for unauthenticated users in the OPAC search results page if ILLOpacUnauthenticatedRequest is enabled. Signed-off-by: David Nind <david@davidnind.com> Created attachment 171371 [details] [review] Bug 36197: Add tests 0) If k-t-d, run updatedatabase (ignore this if testing on a sandbox) 1) Enable ILLModule syspref: {staff_url}/cgi-bin/koha/admin/preferences.pl?tab=&op=search&searchfield=ILLModule 2) No need to install a backend as 35570 is in the tree 3) On a different browser session, without being lgoged in, access the create ILL request OPAC page directly: {opac_url}/cgi-bin/koha/opac-illrequests.pl?method=create&backend=Standard 4) Notice you're presented with the login page, as expected 5) Enable ILLOpacUnauthenticatedRequest: {staff_url}/cgi-bin/koha/admin/preferences.pl?tab=&op=search&searchfield=ILLOpacUnauthenticatedRequest 6) Repeat step 3) Notice you now get the create ILL request form, with some additional inputs at the top specific to an unauthenticated request (first name, last name, e-mail address) 6.5) (optional) Confirm the 'Make an Interlibrary loan request' link exists at the bottom of the search results page, while unauthenticated on OPAC: {opac_url}/cgi-bin/koha/opac-search.pl?idx=&q=music&weight_search=1 This should only show for authenticated OPAC users if ILLOpacUnauthenticatedRequest is off. 7) Test the form, try submitting with some blank fields, change type and library after and before inputing data in the input fields, etc. 8) Submit the form successfully. Notice you're presented with the unauthenticated request submission confirmation screen with a message and request details. 9) Go back to Staff UI, logged in, access ILL requests and confirm the unauthenticated request submitted through the OPAC is there: {staff_url}/cgi-bin/koha/ill/ill-requests.pl 10) Test that you can add a patron afterwards, if needed, by clicking 'Edit request' on the toolbar of the manage request page, and entering a patron ID 11) Test that you're able to 'confirm' the request by clicking 'Confirm request', as if it was a regular 'NEW' request. Additional testing: Make sure existing ILL functionality interacts with this new optional workflow behavior. For this, we're using ILLModuleDisclaimerByType. ILLCheckAvailability or AutoILLBackendPriority can also be used but require more setup (plugins, credentials, etc) 1) Configure ILLModuleDisclaimerByType, visit {staff_url}/cgi-bin/koha/admin/preferences.pl?tab=&op=search&searchfield=ILLModuleDisclaimerByType 2) Click the 'edit' link at the bottom of the syspref and copy the example code from the description into the text box. Save. 3) Repeat the original test plan from above, but make sure the request type is not 'article' (as that type is bypassed). Use 'journal', for example. Submit the request making sure you fill in all mandatory fields. 4) Notice you're now presented with the ILL request disclaimer screen, hit Submit. Notice the request is created as before. 5) Return to Staff UI, logged in, confirm this 2nd unauthenticated request has been created and the type disclaimer info is stored and presented when viewing the request. Run tests (k-t-d only): prove t/db_dependent/Koha/ILL/Backends.t prove t/db_dependent/selenium/opac_ill_requests.t Sponsored-by: NHS England (National Health Service England) Signed-off-by: David Nind <david@davidnind.com> As Matthias mentioned during the Kohacon ILL workshop, there's nothing preventing bots from abusing this at the moment. But it would be similar to anonymous/unauthenticated purchase suggestions with AnonSuggestions enabled. -- That said, perhaps a magic token for EDS to include in the generated URL or a referrer check could be useful to reduce robot spam (which is an existing problem with AnonSuggestions currently). (In reply to David Cook from comment #21) > As Matthias mentioned during the Kohacon ILL workshop, there's nothing > preventing bots from abusing this at the moment. > > But it would be similar to anonymous/unauthenticated purchase suggestions > with AnonSuggestions enabled. > > -- > > That said, perhaps a magic token for EDS to include in the generated URL or > a referrer check could be useful to reduce robot spam (which is an existing > problem with AnonSuggestions currently). There is already an existing captcha system present in opac-memberentry.pl (for patron self registration). Would it make more sense to make use of this here by re utilizing it (doing any necessary refactoring), thus having a single place to extend and maintain going forward and perhaps establish a pattern for public facing forms in Koha, e.g. also apply it to unauthenticated purchase suggestions in the future? (In reply to Pedro Amorim from comment #22) > There is already an existing captcha system present in opac-memberentry.pl > (for patron self registration). > Would it make more sense to make use of this here by re utilizing it (doing > any necessary refactoring), thus having a single place to extend and > maintain going forward and perhaps establish a pattern for public facing > forms in Koha, e.g. also apply it to unauthenticated purchase suggestions in > the future? Hmm there's a thought. That would potentially help against bots. Off the top of my head, I don't think I've heard complaints of bots doing self-registrations. I just remembered that somewhere had a negative captcha, and it looks like opac-suggestions.tt is the one implementing that, but I think most bots can easily bypass that one these days. I think I still feel a bit weird about unauthenticated ILLs, but I suppose they're not really that different to unauthenticated purchase suggestions, although I don't love those either. But then in both cases they're staff mediated anyway... so I suppose that's all right. But yeah... some kind of capture is needed I think. Created attachment 174495 [details] [review] Bug 36197: Add ILLOpacUnauthenticatedRequest sys pref Signed-off-by: David Nind <david@davidnind.com> Created attachment 174496 [details] [review] Bug 36197: Add opac_unauthenticated_ill_requests backend capability to 'Standard' backend Signed-off-by: David Nind <david@davidnind.com> Created attachment 174497 [details] [review] Bug 36197: Consider unauthenticated_ill in 'Standard' create form This also makes sure an empty left side bar exists for opac unauthenticated screens Signed-off-by: David Nind <david@davidnind.com> Created attachment 174498 [details] [review] Bug 36197: Refactor -> opac_available_backends method Signed-off-by: David Nind <david@davidnind.com> Created attachment 174499 [details] [review] Bug 36197: Add UNAUTH Standard request status Assign this new UNAUTH status for unauthenticated requests Signed-off-by: David Nind <david@davidnind.com> Created attachment 174500 [details] [review] Bug 36197: Update how form params are validated Validating an unauth request form requires checking for unauth info fields. Validating a regular authenticated request requires checking for borrower information. Signed-off-by: David Nind <david@davidnind.com> Created attachment 174501 [details] [review] Bug 36197: Update how the request is added: - Do not validate borrower if its an unauthenticated request - Set borrowernumber to null if its an unauthenticated request - Add staff and OPAC notes with unauthenticated request info Signed-off-by: David Nind <david@davidnind.com> Created attachment 174502 [details] [review] Bug 36197: Only check limits for regular requests Skip for unauthenticated requests Signed-off-by: David Nind <david@davidnind.com> Created attachment 174503 [details] [review] Bug 36197: OPAC unauthenticated screen unauth_view to show request details after its been submitted Signed-off-by: David Nind <david@davidnind.com> Created attachment 174504 [details] [review] Bug 36197: Make authentication not required if conditions are met /cgi-bin/koha/opac-illrequests.pl was an authrequired page Now, its authnotrequired if creating or viewing an unauthenticated request Signed-off-by: David Nind <david@davidnind.com> Created attachment 174505 [details] [review] Bug 36197: Unauthenticated patron can always place ILL request if ILLOpacUnauthenticatedRequest Signed-off-by: David Nind <david@davidnind.com> Created attachment 174506 [details] [review] Bug 36197: Only add cardnumber info to request is a user is logged in Signed-off-by: David Nind <david@davidnind.com> Created attachment 174507 [details] [review] Bug 36197: OPAC 'Make an ILL request' link Show the 'Make an ILL request' link for unauthenticated users in the OPAC search results page if ILLOpacUnauthenticatedRequest is enabled. Signed-off-by: David Nind <david@davidnind.com> Created attachment 174508 [details] [review] Bug 36197: Add tests 0) If k-t-d, run updatedatabase (ignore this if testing on a sandbox) 1) Enable ILLModule syspref: {staff_url}/cgi-bin/koha/admin/preferences.pl?tab=&op=search&searchfield=ILLModule 2) No need to install a backend as 35570 is in the tree 3) On a different browser session, without being lgoged in, access the create ILL request OPAC page directly: {opac_url}/cgi-bin/koha/opac-illrequests.pl?method=create&backend=Standard 4) Notice you're presented with the login page, as expected 5) Enable ILLOpacUnauthenticatedRequest: {staff_url}/cgi-bin/koha/admin/preferences.pl?tab=&op=search&searchfield=ILLOpacUnauthenticatedRequest 6) Repeat step 3) Notice you now get the create ILL request form, with some additional inputs at the top specific to an unauthenticated request (first name, last name, e-mail address) 6.5) (optional) Confirm the 'Make an Interlibrary loan request' link exists at the bottom of the search results page, while unauthenticated on OPAC: {opac_url}/cgi-bin/koha/opac-search.pl?idx=&q=music&weight_search=1 This should only show for authenticated OPAC users if ILLOpacUnauthenticatedRequest is off. 7) Test the form, try submitting with some blank fields, change type and library after and before inputing data in the input fields, etc. 8) Submit the form successfully. Notice you're presented with the unauthenticated request submission confirmation screen with a message and request details. 9) Go back to Staff UI, logged in, access ILL requests and confirm the unauthenticated request submitted through the OPAC is there: {staff_url}/cgi-bin/koha/ill/ill-requests.pl 10) Test that you can add a patron afterwards, if needed, by clicking 'Edit request' on the toolbar of the manage request page, and entering a patron ID 11) Test that you're able to 'confirm' the request by clicking 'Confirm request', as if it was a regular 'NEW' request. Additional testing: Make sure existing ILL functionality interacts with this new optional workflow behavior. For this, we're using ILLModuleDisclaimerByType. ILLCheckAvailability or AutoILLBackendPriority can also be used but require more setup (plugins, credentials, etc) 1) Configure ILLModuleDisclaimerByType, visit {staff_url}/cgi-bin/koha/admin/preferences.pl?tab=&op=search&searchfield=ILLModuleDisclaimerByType 2) Click the 'edit' link at the bottom of the syspref and copy the example code from the description into the text box. Save. 3) Repeat the original test plan from above, but make sure the request type is not 'article' (as that type is bypassed). Use 'journal', for example. Submit the request making sure you fill in all mandatory fields. 4) Notice you're now presented with the ILL request disclaimer screen, hit Submit. Notice the request is created as before. 5) Return to Staff UI, logged in, confirm this 2nd unauthenticated request has been created and the type disclaimer info is stored and presented when viewing the request. Run tests (k-t-d only): prove t/db_dependent/Koha/ILL/Backends.t prove t/db_dependent/selenium/opac_ill_requests.t Sponsored-by: NHS England (National Health Service England) Signed-off-by: David Nind <david@davidnind.com> |