Bug 6576 - changing framework while cataloging looses data
Summary: changing framework while cataloging looses data
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: master
Hardware: All All
: PATCH-Sent (DO NOT USE) critical (vote)
Assignee: Srdjan Jankovic
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-12 00:20 UTC by Nicole C. Engard
Modified: 2019-06-27 09:24 UTC (History)
3 users (show)

See Also:
Change sponsored?: Sponsored
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
patch (9.34 KB, patch)
2011-09-12 09:16 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
[Signed Off] bug_6576: Submit when changing framework rather then reloading (9.35 KB, patch)
2011-09-20 21:59 UTC, Liz Rea
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2011-07-12 00:20:36 UTC
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.
Comment 1 Srdjan Jankovic 2011-09-12 09:16:32 UTC
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
Comment 2 Liz Rea 2011-09-20 21:28:08 UTC
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
Comment 3 Liz Rea 2011-09-20 21:50:17 UTC
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.
Comment 4 Liz Rea 2011-09-20 21:59:07 UTC
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>
Comment 5 Ian Walls 2011-09-21 15:38:00 UTC
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
Comment 6 Chris Cormack 2011-09-21 21:28:32 UTC
Pushed, please test
Comment 7 Ian Walls 2011-10-05 15:16:23 UTC
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?
Comment 8 Srdjan Jankovic 2011-10-05 23:56:13 UTC
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.
Comment 9 Nicole C. Engard 2011-10-07 12:22:38 UTC
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
Comment 10 Srdjan Jankovic 2011-10-10 04:07:40 UTC
I have no idea. I can only say that patch has been applied to master, and seems to be working there
Comment 11 Owen Leonard 2011-10-10 12:43:01 UTC
(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?
Comment 12 Nicole C. Engard 2011-10-10 15:45:01 UTC
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
Comment 13 Chris Cormack 2011-10-10 19:34:48 UTC
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
Comment 14 Srdjan Jankovic 2011-10-11 01:43:29 UTC
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.
Comment 15 Nicole C. Engard 2011-10-11 12:43:38 UTC
Srdjan is right, it's working.  

Nicole