Currently, if you change the framework when cataloguing a record (either by adding a new record or duplicating an existing record), all the fields are cleared for that record. However, if you are just editing a record, you can change the framework and the information in the fields will be preserved.
I'm not sure if there's a way to retain the information when switching frameworks while adding a new record, but in the case of duplicating one...the Javascript that switches the framework should still preserve the existing query string...
Created attachment 18860 [details] [review] 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.
Created attachment 18987 [details] [review] 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>
Jonathan, since we have moved to GPL3+ can I update the license text when QAing this?
(In reply to comment #4) > Jonathan, since we have moved to GPL3+ can I update the license text when > QAing this? Yes, of course.
Created attachment 19447 [details] [review] 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>
Pushed to master. Thanks, David!
This patch has been pushed to 3.12.x, will be in 3.12.3. Thanks David!
Pushed to 3.10.x, will be in 3.10.10
*** Bug 6206 has been marked as a duplicate of this bug. ***
Pushed to 3.8.x, will be in 3.8.17.