---- Reported by brian@jhu.edu 2009-08-21 14:33:39 ---- When the user clones a subfield, clicking in the new subfield activates the plug-in, but it modifies the parent rather than the clone. --- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:11 UTC --- This bug was previously known as _bug_ 3544 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3544 Actual time not defined. Setting to 0.0 The original reporter of this bug does not have an account here. Reassigning to the person who moved it here: chris@bigballofwax.co.nz. Previous reporter was brian@jhu.edu.
This appears to still be valid.
Do we have a good example to test for a plugin on a repeatable subfield? All I got was plugins on repeatable fields when trying to test this.
I'm currently working on trying to find the source of this glitch. When cloning subfields, the clone/child tag editor event handler takes the parent subfield id for the onAuth function. I thought the problem came from the AddEventHandler function in cataloguing.js, but comments there say that the function moved to _data since jQuery 1.8. For testing purposes, I used the unimarc_field_128b.pl plugin.
Did you try that? diff --git a/koha-tmpl/intranet-tmpl/prog/js/cataloging.js b/koha-tmpl/intranet-tmpl/prog/js/cataloging.js index 16cf8574968..afc1c3caa42 100644 --- a/koha-tmpl/intranet-tmpl/prog/js/cataloging.js +++ b/koha-tmpl/intranet-tmpl/prog/js/cataloging.js @@ -433,7 +433,7 @@ function AddEventHandlers (oldcontrol, newcontrol, newinputid ) { // newinputid is the id attribute of the cloned controlling input field // Note: This code depends on the jQuery data for events; this structure // is moved to _data as of jQuery 1.8. - var ev= $(oldcontrol).data('events'); + var ev= $._data($(oldcontrol)[0], 'events'); if(typeof ev != 'undefined') { $.each(ev, function(prop,val) { $.each(val, function(prop2,val2) {
Just tried your solution, no visible changes sadly.
I've tried with the upload plugin and I can click on the plugin link to open the pop-up window, select a file and it fill in the correct input with the filepath.
I've heard a similar complaint recently, could it be a browser issue?
I see you linked bug 30975 already, could this be a duplicate?
You can also recreate this problem if you clone tag 007, when you click on the tag editor icon it should use marc21_field_007.pl but it does not