Bug 10448: can now change framework after duplicating bib record
authorDavid Cook <dcook@prosentient.com.au>
Wed, 12 Jun 2013 01:24:09 +0000 (11:24 +1000)
committerChris Hall <followingthepath@gmail.com>
Tue, 20 Aug 2013 09:12:58 +0000 (21:12 +1200)
Changing the framework in the MARC editor immediately after duplicating
a bib record no longer clears the fields.

This patch changes the Changefwk Javascript function so that it passes
the "op" value and the "biblionumberdata" (as the biblionumber) from
addbiblio.pl back to itself, when submitting the form in order to
change the framework.

The reason we need to do this is because the form in addbiblio.tt
is hard-coded to always submit an "op" value of "addbiblio". Currently,
we need to have it hard-coded to "addbiblio", because all the magic
happens in addbiblio.pl when there is an "op" of "addbiblio". If we
always passed the "actual" "op" value, such as "duplicate", nothing
would ever happen when we clicked "save". It seems to me that this
is a flaw in the design of addbiblio.pl.

If we pass the "op" and "biblionumber" when changing frameworks, we're
able to tell addbiblio.pl that we're still wanting to "duplicate" this
"X" biblionumber. However, by having the form still hard-coded to
"addbiblio", when we hit save, the form will do the magic, check if
it's a duplicate, and save the record (or prompt for action if it
is a duplicate).

--

I also noticed that if you make changes to a record, then change
the framework before saving, your changes get cleared (since the
original record from the database is loaded when the page reloads).
It seems to me that this is a bug. Changing the framework should
change the layout while preserving the content. I think most users
would assume that when changing the framework.

This patch also introduces another hidden input into addbiblio.tt and
the Changefwk Javascript called "changed_framework". Basically, if
the Changefwk Javascript is run, it tells addbiblio.pl that the
framework is changed, and it uses the posted data from the form
(which we have been modifying) instead of reloading the record from
the database.

--

Test Plan:

A) Before Applying Patch:

To Show That Changing the Framework Erases All Fields When
Duplicating a Record:

1) Go to any bib record
2) Go to Edit > Edit as new (duplicate). You should see filled
in fields.
3) Change the framework to any other framework than the one
that is currently specified.
4) Note that every single field is now blank

To Show That Changing the Record then Changing the Framework
Ignores Changes, When Editing a Record

5) Go to any bib record
6) Go to Edit.
7) Change the title of the record to "I've changed the title".
8) Change the framework to any other framework than the one that is currently specified.
9) Look at the title. You'll notice it is the original title, and NOT "I've changed the title".

B) Apply the Patch

Also, clear your memcache and shift+refresh your screen. You don't want to use cached templates/javascript.

C) After Applying the Patch

Repeat Steps 1-3 and 5-8.

You should now notice that changing the framework when duplicating the item does not clear all the fields.

You should also notice that any changes you make prior to changing the framework will still exist after changing it.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit ca33b7fc635d93b3029831da7496372fb34c798f)
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Works as expected.
(cherry picked from commit 98e397d9a5c5cbd3d2aa88cd0044c24a7d75ff72)
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
(cherry picked from commit 98e397d9a5c5cbd3d2aa88cd0044c24a7d75ff72)
Signed-off-by: Chris Hall <followingthepath@gmail.com>
(cherry picked from commit 502f35ea0a2405974d20a51ac2b42eb18fd1d4e2)

cataloguing/addbiblio.pl
koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/addbiblio.tt

index 562acd3..fb3dedd 100755 (executable)
@@ -744,6 +744,7 @@ if ($frameworkcode eq 'FA'){
     $userflags = 'fast_cataloging';
 }
 
+my $changed_framework = $input->param('changed_framework');
 $frameworkcode = &GetFrameworkCode($biblionumber)
   if ( $biblionumber and not($frameworkcode) and $op ne 'addbiblio' );
 
@@ -964,7 +965,10 @@ elsif ( $op eq "delete" ) {
         $biblionumber = "";
     }
 
-    if ( $record ne -1 ) {
+    if($changed_framework eq "changed"){
+        $record = TransformHtmlToMarc( $input );
+    }
+    elsif( $record ne -1 ) {
 #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;
index 15f4919..e47fa6d 100644 (file)
@@ -256,7 +256,9 @@ function GetZ3950Terms(){
 
 function Changefwk(FwkList) {
     var f = document.f;
-    f.op.value = "";
+    f.op.value = "[% op %]";
+    f.biblionumber.value = "[% biblionumberdata %]";
+    f.changed_framework.value = "changed";
     f.submit();
 }
 
@@ -817,6 +819,7 @@ function unHideSubfield(index,labelindex) { // FIXME :: is it used ?
         <input type="hidden" name="frameworkcode" value="[% frameworkcode %]" />
         <input type="hidden" name="biblionumber" value="[% biblionumber %]" />
         <input type="hidden" name="breedingid" value="[% breedingid %]" />
+        <input type="hidden" name="changed_framework" value="" />
 
 <div id="addbibliotabs" class="toptabs numbered">
        <ul>[% FOREACH BIG_LOO IN BIG_LOOP %]