I did a few tests of this and every time a different amount of data was lost, but data was lost every time. If you're cataloging a new record in the default framework and then after entering data change the framework to another framework it loses data that was in fields that appear in both frameworks. This could cause someone to lose a lot of work.
Created attachment 5403 [details] [review] patch This will only apply for new records, will not apply for modifying existing ones. Please check if there are no fields that are retaining values that are not applicable for the new (changed) framework
I'm not able to apply this patch: Applying: bug_6576: Submit when changing framework rather then reloading error: patch failed: koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/addbiblio.tt:776 error: koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/addbiblio.tt: patch does not apply Patch failed at 0001 bug_6576: Submit when changing framework rather then reloading
That's my bad I left off the -3 and git bz wouldn't apply it. git am -3 applied it just fine. Apologies, Srdjan.
Created attachment 5484 [details] [review] [Signed Off] bug_6576: Submit when changing framework rather then reloading TransformHtmlToMarc(): changed interface - no point passing params when they can be accessed from $cgi Signed-off-by: Liz Rea <lrea@nekls.org>
Catches all usage of TransformHtmlToMarc and updates correctly. Usage within the subroutine has been updated to reflect the new data type. Some change to spacing, and a change to some of the JS on the addbiblio template. All in all, looks good, marking as Passed QA
Pushed, please test
Srdjan, The addition of this logic to addbiblio.pl is causing bug 6974: + if ( $record eq -1 ) { + $record = TransformHtmlToMarc( $input ); + } + else { #FIXME: it's kind of silly to go from MARC::Record to MARC::File::XML and then back again just to fix the encoding - eval { - my $uxml = $record->as_xml; - MARC::Record::default_record_format("UNIMARC") - if ( C4::Context->preference("marcflavour") eq "UNIMARC" ); - my $urecord = MARC::Record::new_from_xml( $uxml, 'UTF-8' ); - $record = $urecord; - }; + eval { + my $uxml = $record->as_xml; + MARC::Record::default_record_format("UNIMARC") + if ( C4::Context->preference("marcflavour") eq "UNIMARC" ); + my $urecord = MARC::Record::new_from_xml( $uxml, 'UTF-8' ); + $record = $urecord; + }; + } Can you help me understand the reasoning behind adding the conditional check for $record eq -1? What does that fix?
That fixes generating a trapped exception error when attempting to correct encoding on a non-existing record when op is not 'addbiblio'. I see that I probably did too much and will correct that.
This bug is back after a fetch this morning. Something applied last night reverted this functionality. I can't change the framework when cataloging or all the fields get emptied. Nicole
I have no idea. I can only say that patch has been applied to master, and seems to be working there
(In reply to comment #10) > I have no idea. I can only say that patch has been applied to master, and seems > to be working there Except for Bug 6959 and Bug 6974. Since the patch for this bug seems to have caused those, I'm guessing the patches for those has caused this to resurface?
What is the process when that happens? Do those patches have to be fixed or does this one need a new patch? Chris or Ian can tell us. Nicole
I think fixing one of the other ones, that undid this fix is probably what needs to happen You should be able to test which one caused it, by reverting them, one at a time
Again, I am a bit confused here. I have a kc/master checkout. * all 6576, 6959 and 6974 are applied * I tried going from Default to Book framework and back again: - page was submitted every time (as expected) - on the first page ( 0 ) 0 LEADER, 8 GENERAL INFO, 20 ISBN and 24 OTHER STANDARD IDENTIFIER were preserved, as well as 942 "Source of classification" and "item type" Can you please describe what was expected, and what happened.
Srdjan is right, it's working. Nicole