http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10448 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=6067 -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10448 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff Assignee|gmcharlt@gmail.com |dcook@prosentient.com.au --- Comment #2 from David Cook <dcook@prosentient.com.au> --- Created attachment 18860 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=18860&action=edit Bug 10448 - Changing framework when cataloguing clears all 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. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10448 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #18860|0 |1 is obsolete| | --- Comment #3 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 18987 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=18987&action=edit Bug 10448 - Changing framework when cataloguing clears all 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> -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10448 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@biblibre.co | |m --- Comment #5 from Jonathan Druart <jonathan.druart@biblibre.com> --- (In reply to comment #4)

Jonathan, since we have moved to GPL3+ can I update the license text when QAing this?

Yes, of course. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10448 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #18987|0 |1 is obsolete| | --- Comment #6 from Chris Cormack <chris@bigballofwax.co.nz> --- Created attachment 19447 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19447&action=edit Bug 10448 - Changing framework when cataloguing clears all 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> -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10448 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to Master |Pushed to Stable CC| |tomascohen@gmail.com --- Comment #8 from Tomás Cohen Arazi <tomascohen@gmail.com> --- This patch has been pushed to 3.12.x, will be in 3.12.3. Thanks David! -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10448 Nicole C. Engard <nengard@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nengard@gmail.com --- Comment #10 from Nicole C. Engard <nengard@gmail.com> --- *** Bug 6206 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.