Summary: | Determine maximum length of some fields or subfields when cataloguing | ||
---|---|---|---|
Product: | Koha | Reporter: | Juan Romay Sieira <juan.sieira> |
Component: | Cataloging | Assignee: | Juan Romay Sieira <juan.sieira> |
Status: | CLOSED FIXED | QA Contact: | Ian Walls <koha.sekjal> |
Severity: | critical | ||
Priority: | P3 | CC: | duncan, henridamien.laurent, jcamins, magnus, paul.poulain |
Version: | 3.8 | ||
Hardware: | All | ||
OS: | All | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Bug Depends on: | |||
Bug Blocks: | 7850, 7855, 8018 | ||
Attachments: |
Path to this enhancement
Patch to apply in current master Patch to current master Patch to apply in current master patch signed off patch signed off |
Description
Juan Romay Sieira
2011-11-24 17:54:54 UTC
Created attachment 6395 [details] [review] Path to this enhancement Apply the patch and in Administration › MARC Frameworks , edit the MARC Structure of a framework, edit the subfields of a field and under "more contraints" there is a new input "Max length" to determine the max characters of this subfield. Create or modify a biblio/item to see it. After fixing a merge error in the updatedatabase.pl file the patch applied fine. The max length field can successfully be found where it is supposed to be. However, applying the patch also prevented me from being able to add new MARC records. On going to the add screen none of the input fields are present and it just remains blank. Hi Duncan, from your description I think this is 'failed qa'. Created attachment 6864 [details] [review] Patch to apply in current master This patch applies to current master I applied the patch again and haven't found any error. I setup a max length to one of the subfields of the 245 and has done what it supposed to do. I uploaded another patch compatible with the current master. Created attachment 7537 [details] [review] Patch to current master The update included with this patch is MARC21-specific, but will operate on UNIMARC databases as well. Please correct the update to handle the three supported MARC flavours appropriately. Created attachment 8361 [details] [review] Patch to apply in current master The patch was modified to handle the supported MARC flavours (in syspref) in updatedatabase Created attachment 8454 [details] [review] patch signed off Created attachment 8561 [details] [review] patch signed off Previous signedoff patch does not apply (fatal: sha1 information is lacking or useless (C4/Biblio.pm). Repository lacks necessary blobs to fall back on 3-way merge.) This one is good. Marked as Passed QA As far as I can see, this adds the maxlength column to installations that are upgraded, but what about fresh installs? Shouldn't maxlength be added to all existing frameworks, or am I missing something? Hi Magnus, The patch adds a default value for this new column: `maxlength` int(4) NOT NULL DEFAULT '9999' You shouldn't have a problem for a fresh install with a default value. But updatedatabase changes the default for a couple of fields: +$DBversion = "3.07.00.XXX"; +if ( C4::Context->preference("Version") < TransformToNum($DBversion) ) { + $dbh->do(" + ALTER TABLE `marc_subfield_structure` ADD `maxlength` INT( 4 ) NOT NULL DEFAULT '9999'; + "); + $dbh->do(" + UPDATE `marc_subfield_structure` SET maxlength=24 WHERE tagfield='000'; + "); + $dbh->do(" + UPDATE marc_subfield_structure SET maxlength = IF ((SELECT value FROM systempreferences WHERE variable = 'marcflavour')='MARC21','40','9999') WHERE tagfield='008'; + "); + $dbh->do(" + UPDATE marc_subfield_structure SET maxlength = IF ((SELECT value FROM systempreferences WHERE variable = 'marcflavour')='UNIMARC','36','9999') WHERE tagfield='100'; + "); + print "Upgrade to $DBversion done (Add new field maxlength to marc_subfield_structure)\n"; + SetVersion($DBversion); +} + So all marcflavours on upgraded installations will have maxlength = 24 for 000, while fresh installs will have 9999. And upgraded MARC21 installations will have maxlength = 40 for field 008 while fresh installations will have maxlength = 9999. Might not be much of a problem, but it will lead to subtle differences in installations depending on their history and perhaps a potential for future confusion. You're not missing nothing, I missed to include in fresh installs this change. I'll push in a few minutes those files to update fields like 000, 008, 100 (unimarc)... (In reply to comment #14) > You're not missing nothing, I missed to include in fresh installs this > change. I'll push in a few minutes those files to update fields like 000, > 008, 100 (unimarc)... Yay! I'm working on a patch to change some things in the NORMARC frameworks anyway (bug 7850), so I'll include the maxlength column for all subfields there, with 000 = 24 and 008 = 40. That should take care of fresh NORMARC installs. To be complete, updatedatabase.pl should do this part for NORMARC too: UPDATE marc_subfield_structure SET maxlength = IF ((SELECT value FROM systempreferences WHERE variable = 'marcflavour')='NORMARC','40','9999') WHERE tagfield='008'; Hm, bit confused here - from the comments I think we still need a patch to fix the fields on upgraded installations? I am changing bug status - please reset if I missed something! There is a separate bug for the followup: Bug 7855. No this is not obsolete. Magnus and me uploaded two patches that complemented this one, bug 7855 and bug 7850. On this patch, 7263, in a fresh install the length of the fields 000, 008, 100 ... is 9999, not the correct length. With patches 7855 and 7850 we fixed this sutuation. Ah, I thought the patch had been pushed already - do you want to reset the patch here? I am adding the other bugs as dependending on this. yeah, kf, that's ok. As far as I can see this was originally signed off - setting it back to that. And I sure hope this and bug 7855 make it into 3.8, because bug 7850 relies on these and it is already pushed to master... (In reply to comment #21) > As far as I can see this was originally signed off - setting it back to > that. > > And I sure hope this and bug 7855 make it into 3.8, because bug 7850 relies > on these and it is already pushed to master... Magnus, I don't understand why this has been switched to signed-off : the patch attached has been pushed (020c095 Bug 7263 - Determine maximum length of some fields or subfields when cataloguing a biblio or an item) The follow-up 7855 is still to be signed-off and pushed though Yes sorry - I got confused! Setting it back to "Pushed to master" now! There have been no further reports of problems so I am marking this bug resolved. |