The UNIMARC cataloging plugin unimarc_field_4XX.pl no longer performs searches after the implementation of CSRF protection changes in Bug 34478. The template unimarc_field_4XX.tt was updated to use op=cud-do_search to comply with the new security requirements, but the corresponding Perl script unimarc_field_4XX.pl was not updated to handle the cud- prefix or the renamed parameter. As a result, when a user clicks the "Search" button in the plugin popup, the script fails to recognize the operation and doesn't return any results. This issue specifically affects UNIMARC installations. Steps to reproduce: Use a Koha instance configured for UNIMARC. Go to Cataloging -> Add MARC record. Locate a 4XX field (e.g., 410, 411, 461) and click the plugin button (...) to open the search popup. Enter any search term (e.g., a title or author) and click "Search". Observe that the page simply reloads or shows the search form again without any results, despite matches existing in the database. Check the logic in cataloguing/value_builder/unimarc_field_4XX.pl: it likely checks for if ($op eq 'do_search'), which is now never true because the value passed is cud-do_search. Actual results: The plugin stays on the search form and does not execute the search logic. Expected results: The plugin should execute the search and display the list of records to link.
Possible solution is to find in unimarc_field_4XX.pl the string elsif ( $op eq "do_search" ) { and change it to: elsif ( $op eq "do_search" || $op eq "cud-do_search" ) {
(In reply to Oleg Vasylenko from comment #1) > Possible solution is to find in unimarc_field_4XX.pl the string > elsif ( $op eq "do_search" ) { > and change it to: > elsif ( $op eq "do_search" || $op eq "cud-do_search" ) { See also this bug 40307 I am interested in this type of bug because I am working on updating the coding guideline for 5.1 This op was prefixed with cud- by a script as a result of bug 34478. One one hand if the request does not result in making any changes to the database, then it doesn't necessarily need to be POST and it could be changed to GET. GET could be preferred in cases where it would be convenient for users to be able to bookmark/share a url. POST would be preferred for scalability when the form needs to be able to send many parameters/values that would exceed the character limit in a url. In these cases there are examples in the codebase of ops like cud-do_search, cud-search, and cud-form I don't know enough about this unimarc plugin to know which solution is better for this case, but the similar bug 40307 has a patch changing the request to GET.