Bug 42095

Summary: UNIMARC: Cataloging plugin unimarc_field_4XX.pl broken after Bug 34478 (op-cud)
Product: Koha Reporter: Oleg Vasylenko <synapse.ova>
Component: CatalogingAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: blocker    
Priority: P1 - high CC: blawlor, m.de.rooy
Version: Main   
Hardware: All   
OS: All   
GIT URL: Initiative type: ---
Sponsorship status: --- Comma delimited list of Sponsors:
Crowdfunding goal: 0 Crowdfunding committed: 0
Crowdfunding contact: Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:
Bug Depends on: 34478    
Bug Blocks:    

Description Oleg Vasylenko 2026-03-13 14:06:11 UTC
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.
Comment 1 Oleg Vasylenko 2026-03-13 14:12:38 UTC
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" ) {
Comment 2 Brendan Lawlor 2026-03-13 15:15:38 UTC
(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.