| Summary: | hardcoded insert incompatible with UNIMARC | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Paul Poulain <paul.poulain> |
| Component: | Database | Assignee: | Galen Charlton <gmcharlt> |
| Status: | CLOSED FIXED | QA Contact: | Bugs List <koha-bugs> |
| Severity: | major | ||
| Priority: | P5 - low | CC: | chris, magnus, paul.poulain |
| Version: | 3.6 | ||
| Hardware: | All | ||
| OS: | All | ||
| GIT URL: | Initiative type: | --- | |
| Sponsorship status: | --- | Crowdfunding goal: | 0 |
| Patch complexity: | --- | Documentation contact: | |
| Documentation submission: | Text to go in the release notes: | ||
| Version(s) released in: | Circulation function: | ||
| Attachments: | Bug 6931 : Only update frameworks for the correct marcflavour | ||
It seems this wasn't fixed :( Perhaps still worth fixing for libraries updating from older versions?
3976 $DBversion = "3.03.00.015";
3977 if (C4::Context->preference("Version") < TransformToNum($DBversion)) {
3978 my $sth = $dbh->prepare("INSERT INTO `marc_subfield_structure` (`tagfield`, `tagsubfield`, `liblibrarian`, `libopac`, `repeatable`, `mandatory`, `kohafield`,
3979 `tab`, `authorised_value`, `authtypecode`, `value_builder`, `isurl`, `hidden`, `frameworkcode`, `seealso`, `link`, `defaultvalue`)
3980 VALUES ( ?, '9', '9 (RLIN)', '9 (RLIN)', 0, 0, '', 6, '', '', '', 0, -5, '', '', '', NULL)");
3981 $sth->execute('648');
3982 $sth->execute('654');
3983 $sth->execute('655');
3984 $sth->execute('656');
3985 $sth->execute('657');
3986 $sth->execute('658');
3987 $sth->execute('662');
3988 $sth->finish;
3989 print "Upgrade to $DBversion done (Bug 5619: Add subfield 9 to marc21 648,654,655,656,657,658,662)\n";
3990 SetVersion ($DBversion);
3991 }
Created attachment 9264 [details] [review] Bug 6931 : Only update frameworks for the correct marcflavour This bug will still effect anyone coming from 3.2.x or previous, of which there are still hundreds of libraries. So i think the fix is worth doing. patch is OK QA comment: trivial patch. However, one question for magnus: are those fields relevant in NORMARC ? Shouldn't we use unless $marcflavour eq 'unimarc' ? I'll push the patch, because it fixes a very annoying bug for UNIMARC users. Note that, if you think there are no NORMARC libraries using 3.2 now, you shouldn't care for this patch ! Of these fields, NORMARC only uses 655, 656 and 658. In all of those subfield 9 is used for some kind of language information, and this is already defined for the frameworks in Koha. So updating subfield 9 the same way it's done for MARC21 here would not be a good idea. Of course, this will spell trouble for NORMARC libraries wanting to use authorities, but I think we'll tackle that when (and if) we get there. Hopefully NORMARC will be obsolete before that... ;-) There have been no further reports of problems so I am marking this bug resolved. |
In updatedatabase, the $DBversion = "3.03.00.015"; contains : my $sth = $dbh->prepare("INSERT INTO `marc_subfield_structure` (`tagfield`, `tagsubfield`, `liblibrarian`, `libopac`, `repeatable`, `mandatory`, `kohafield`, `tab`, `authorised_value`, `authtypecode`, `value_builder`, `isurl`, `hidden`, `frameworkcode`, `seealso`, `link`, `defaultvalue`) VALUES ( ?, '9', '9 (RLIN)', '9 (RLIN)', 0, 0, '', 6, '', '', '', 0, -5, '', '', '', NULL)"); $sth->execute('648'); $sth->execute('654'); $sth->execute('655'); $sth->execute('656'); $sth->execute('657'); $sth->execute('658'); $sth->execute('662'); =>> it's marcflavour independant and will result in some pain in UNIMARC ! (648...662 should not exist in standard UNIMARC so, 1- dead data will be added and 2-if a library uses those fields for local use, that will break a lot of things (ie : the 6xx are used for authorities, the $9 for authid, so, I don't imagine what the result will be !) A simple if syspref("marcflavour") eq "marc21" before the insert should fix the bug