Subscriptions can't be created because of an HTTP 500 and the following message in the plack error log: "Control fields (generally, just tags below 010) do not have subfields, use data() at /usr/share/koha/lib/Koha/Object/Mixin/AdditionalFields.pm line 68." The workaround by Joubu (many thanks!) in the Koha chat was to look whether in Administration > Additional fields > Table 'subscription' (/cgi-bin/koha/admin/additional-fields.pl?tablename=subscription) a MARC field was present that was a control field (ie. without $ field/subfield separator). We indeed had a 001 configured there with MARC field mode "Get value from MARC record" and Searchable=Yes Removing this solved the problem, but perhaps subscriptions should also work if a control field is configured in the place mentioned above? Another thing is that we are not completely sure if the error was produced when we upgraded from 22.05 or if it was present there as well with the additional field set.
Confirmed in current development version. Tested with 001 and 001@. It would be nice if we could add support as the 001 would be really useful.
Created attachment 173777 [details] [review] Bug 34989: Subscription cannot be added if a control field is set up in "Additional Fields" parameter Test plan for MARC21: 1 - Create a subscription 2 - Go to administration -> aditional fields add a field for any CONTROL field existing in your subscription for example 005 3 - Also create an additional field for 245$a (check non regression) 4 - On the subscription page: Edit -> Edit subscription -> Next -> Save subscription -> You get: "Internal server error" 5 - Apply patch 6 - Repeat 4, you have no error anymore. On the subscription page you can see both additional fields.
Created attachment 173778 [details] [review] Bug 34989: Subscription cannot be added if a control field is set up in "Additional Fields" parameter Test plan for MARC21: 1 - Create a subscription 2 - Go to administration -> aditional fields add a field for any CONTROL field existing in your subscription for example 005 3 - Also create an additional field for 245$a (check non regression) 4 - On the subscription page: Edit -> Edit subscription -> Next -> Save subscription -> You get: "Internal server error" 5 - Apply patch 6 - Repeat 4, you have no error anymore. On the subscription page you can see both additional fields.
I couldn't replicate the issue - steps 2-5. The subscription I created had an 001 and 005 value in the record. What I entered in the additional field form (for the subscription table): - Name: BZ34989-1 - Authorized value category: None - Repeatable: left blank - MARC field: 005 - MARC field mode: Get value from MARC record (not modifiable) - Searchable: selected
Created attachment 174979 [details] [review] Bug 34989: [23.11] Subscription cannot be added if a control field is set up in "Additional Fields" parameter Test plan for MARC21: 1 - Create a subscription 2 - Go to administration -> aditional fields add a field for any CONTROL field existing in your subscription for example 005 3 - Also create an additional field for 245$a (check non regression) 4 - On the subscription page: Edit -> Edit subscription -> Next -> Save subscription -> You get: "Internal server error" 5 - Apply patch 6 - Repeat 4, you have no error anymore. On the subscription page you can see both additional fields.
Created attachment 174980 [details] [review] Bug 34989: Subscription cannot be added if a control field is set up in Additional Fields parameter Test plan for main and MARC21: 1 - Apply bug 38528 2 - Create a subscription 3 - Go to administration -> aditional fields add a field for any CONTROL field existing in your subscription for example 005 4 - Also create an additional field for 245$a (check non regression) 5 - On the subscription page: Edit -> Edit subscription -> Next -> Save subscription -> You get: "Internal server error" 6 - Apply patch 7 - Repeat 4, you have no error anymore. On the subscription page you can see both additional fields.
Hi @David, thanks for paying attention to this patch :) Sry for taking long time to answer, I had to dig a bit. Unfortunately I had mistakenly tested it on top of 23.11, and as far as I investigated, main is quite broken concerning additional fields using get, that's why you don't reproduce the bug. On main, 'get' fields are not fetched from database anymore (I reported Bug 38528 to this end). To reproduce the bug, it is necessary to force a data to be present in additional_field_values, hence I added the install of Bug 38528 in the test plan, it is also possible to add the proper row in the database. Note: I did not add it as a dependency since the patch applies on main without Bug 38528 and the requirement to reproduce the bug is only to have the proper data in additional_field_values.