Actually a long standing fix already..
Created attachment 184919 [details] [review] Bug 40559: Fix noisy warning in MARCdetail Rebased for 25.06. Resolves: [2025/07/31 10:59:02] [WARN] Use of uninitialized value in string eq at /usr/share/koha/catalogue/MARCdetail.pl line 203. Test plan: Check if warn disappears with this patch. Trigger the warn by opening catalogue/MARCdetail on staff view. (Should be enough with a normal MARC record.) Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Trivial. Self SO
Created attachment 186407 [details] [review] Bug 40559: cleanup
Would you accept this follow-up?
Also wondering.... next if ( $tagslib->{ $fields[$x_i]->tag() }->{ $subf[$i][0] }->{tab} // q{} ) ne $tabloop; # Note: defaulting to '0' changes behavior! Why?
Will check
(In reply to Jonathan Druart from comment #4) > Would you accept this follow-up? I feel that we should move it on its own report. The noisy warning patch is just about 1 line of code (-1,+3) and can be backported. The cleanup could go on its own and would be an enhancement, right?
(In reply to Jonathan Druart from comment #5) > Also wondering.... > > next > if ( $tagslib->{ $fields[$x_i]->tag() }->{ $subf[$i][0] > }->{tab} // q{} ) ne > $tabloop; # Note: defaulting to '0' changes behavior! > > Why? Since tabloop can be zero? Or do you mean something else?
(In reply to Marcel de Rooy from comment #8) > (In reply to Jonathan Druart from comment #5) > > Also wondering.... > > > > next > > if ( $tagslib->{ $fields[$x_i]->tag() }->{ $subf[$i][0] > > }->{tab} // q{} ) ne > > $tabloop; # Note: defaulting to '0' changes behavior! > > > > Why? > > Since tabloop can be zero? Or do you mean something else? The if syntax: next if ( $var ) ne $tabloop;
(In reply to Marcel de Rooy from comment #7) > (In reply to Jonathan Druart from comment #4) > > Would you accept this follow-up? > > I feel that we should move it on its own report. The noisy warning patch is > just about 1 line of code (-1,+3) and can be backported. > The cleanup could go on its own and would be an enhancement, right? Well. Lets get this moving again now. I proposed to move the second patch. And I did so now. See bug 41153. Will take a look there further.
Comment on attachment 186407 [details] [review] Bug 40559: cleanup Moved to new report
(In reply to Marcel de Rooy from comment #1) > Trigger the warn by opening catalogue/MARCdetail on staff view. (Should > be enough with a normal MARC record.) Unfortunately, things are not as easy as they may seem. This (obviously) depends on the value of marc_subfield_structure.kohafield. I checked a production db and my dev db. And they were not the same. So I could trigger this on production easier than in dev. But note that this column is null by default: `kohafield` varchar(40) DEFAULT NULL,
PROD | 020 | a | biblioitems.isbn | | 020 | q | NULL | DEV | 020 | a | biblioitems.isbn | | 020 | q | |
Created attachment 188796 [details] [review] Bug 40559: Fix noisy warning in MARCdetail Rebased for 25.06. Resolves: Use of uninitialized value in string eq at /usr/share/koha/catalogue/MARCdetail.pl line 203. Test plan: Make sure that there is a combination of framework/field/subfield having an entry in marc_subfield_structure where kohafield is NULL. To force this for default fw on 020$q: update marc_subfield_structure set kohafield=NULL where tagfield='020' and tagsubfield='q' and frameworkcode=''; Pick a biblio in this framework having that field/subfield. Or create a 020 with $q filled. Hit catalogue/MARCdetail now. Without this patch, it triggers the warn. With this patch, it does not. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
I amended the commit message/test plan to be more accurate. Given the trivial change, the age of this patch (coming from 2020), the time spent on it now again and Jonathan having seen it too, taking the liberty to pass QA on it now. And continuing with the follow-up.
Nice work everyone! Pushed to main for 25.11
Nice work everyone! Pushed to 25.05.x
Pushed to 24.11.x for 24.11.11