Full details here: http://koha.1045719.n5.nabble.com/Repeat-this-Tag-not-working-td5914615.html Description: I've setup a completely new VM: Debian GNU/Linux 8.6 (jessie) MariaDB Ver 14.14 Distrib 5.5.53 Apache/2.4.10 (Debian) Installed the defaults in fr-FR Choose Cataloging -> New Record -> Default Framework Filed the mandatory fields. If I try to duplicate 701 it will jump to the top of the page If I try to duplicate 711 I have no problem. Conclusion is: If I try to duplicate any field that contains a Drop Menu (with authorized values) it will jump to the top of page. If there is no Drop Menu it will clone ok. If I choose a value from the Authorized Values, than In can duplicate it. But, when I save it, that fields are not saved.
Created attachment 58464 [details] [review] Bug 17817: Temporarily remove select2 where is is used If you try to clone a field (or subfield) which contains at least a subfield linked to authorized values, you will get a JS error and the field will not be cloned. I have failed trying to propose a fix in a reasonable delay so I prefer to simply deactivate the feature. Test plan: Edit a bibliographic record, an item and use the batch item modification tool. You should see simple selects
Created attachment 58465 [details] [review] [DO NOT PUSH] Bug 17817: This is just a try This does not work correctly: - width is wrongly calculated - "Move up" raises a JS error
Created attachment 58579 [details] [review] [SIGNED-OFF] Bug 17817: Temporarily remove select2 where is is used If you try to clone a field (or subfield) which contains at least a subfield linked to authorized values, you will get a JS error and the field will not be cloned. I have failed trying to propose a fix in a reasonable delay so I prefer to simply deactivate the feature. Test plan: Edit a bibliographic record, an item and use the batch item modification tool. You should see simple selects Signed-off-by: Owen Leonard <oleonard@myacpl.org>
*** Bug 17863 has been marked as a duplicate of this bug. ***
Created attachment 58817 [details] [review] Bug 17817: Fix cloning subfields using select2 Based on Jonathan's patch (the DO NOT PUSH one), I put together this fix. What was changed is that select2 is reinitialized only after the cloned element has been appended to the DOM (so that select2 can correctly calculate the field's width). Also, I changed the selectors that searched for the line divs (for reordering) and for the subfield's input element (for erasing the field's value) to be more specific, since select2 introduced divs that broke some assumptions about the expected HTML structure
(In reply to Patricio Marrone from comment #5) Hi Patricio, Can you confirm that your patch fixes the following: - width is wrongly calculated - "Move up" raises a JS error ?
(In reply to Jonathan Druart from comment #6) > (In reply to Patricio Marrone from comment #5) > > Hi Patricio, > Can you confirm that your patch fixes the following: > - width is wrongly calculated > - "Move up" raises a JS error > ? Hi Jonathan! Short answer: yes. I checked that - The width is the same as the one from the cloned line. This was fixed by first appending the cloned element to the dom and then reactivating select2, so that it can calculate the width. - Moving up should work. select2 introduces some divs which broke the present assumptions that all divs were lines. I added more specific selectors to choose what's a line and what's not. This could use some regression testing to check that other kind of fields still work correctly (that is, textfields, textareas...). I did test that they worked to the limits of my not very extensive Koha knowledge.
There is a regression on moving subfields up to the top.
Created attachment 58823 [details] [review] Bug 17817: Fix cloning subfields using select2 Based on Jonathan's patch (the DO NOT PUSH one), I put together this fix. What was changed is that select2 is reinitialized only after the cloned element has been appended to the DOM (so that select2 can correctly calculate the field's width). Also, I changed the selectors that searched for the line divs (for reordering) and for the subfield's input element (for erasing the field's value) to be more specific, since select2 introduced divs that broke some assumptions about the expected HTML structure
Created attachment 58824 [details] [review] Bug 17817: (Follow up) Fix reordering subfields issues Authority controlled subfields have invisible divs which produced a strange behavior when reordering (multiple clicks were needed to push a subfield up over an authority controlled subfield)
Created attachment 58827 [details] [review] Bug 17817: Fix cloning subfields using select2 Based on Jonathan's patch (the DO NOT PUSH one), I put together this fix. What was changed is that select2 is reinitialized only after the cloned element has been appended to the DOM (so that select2 can correctly calculate the field's width). Also, I changed the selectors that searched for the line divs (for reordering) and for the subfield's input element (for erasing the field's value) to be more specific, since select2 introduced divs that broke some assumptions about the expected HTML structure Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 58828 [details] [review] Bug 17817: (Follow up) Fix reordering subfields issues Authority controlled subfields have invisible divs which produced a strange behavior when reordering (multiple clicks were needed to push a subfield up over an authority controlled subfield) Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Works as expected. Nice catch with reordering!
Still 2 regressions: 1/ On the add item form, it does not work 2/ Try to clone a whole field containing select2: TypeError: divs[i].getAttribute(...) is null You know, I really think that we should go first with my patch, then try to fix it on another bug report. This is critical as it impacts stable releases.
Created attachment 58844 [details] [review] Bug 17817: Fix cloning subfields using select2 Based on Jonathan's patch (the DO NOT PUSH one), I put together this fix. What was changed is that select2 is reinitialized only after the cloned element has been appended to the DOM (so that select2 can correctly calculate the field's width). Also, I changed the selectors that searched for the line divs (for reordering) and for the subfield's input element (for erasing the field's value) to be more specific, since select2 introduced divs that broke some assumptions about the expected HTML structure
Created attachment 58845 [details] [review] Bug 17817: (Follow up) Fix reordering subfields issues Authority controlled subfields have invisible divs which produced a strange behavior when reordering (multiple clicks were needed to push a subfield up over an authority controlled subfield)
I added fixes to the regressions discovered by Jonathan. Are there more places where these select2 fields need to be cloned?
Created attachment 58847 [details] [review] [SIGNED-OFF] Bug 17817: Fix cloning subfields using select2 Based on Jonathan's patch (the DO NOT PUSH one), I put together this fix. What was changed is that select2 is reinitialized only after the cloned element has been appended to the DOM (so that select2 can correctly calculate the field's width). Also, I changed the selectors that searched for the line divs (for reordering) and for the subfield's input element (for erasing the field's value) to be more specific, since select2 introduced divs that broke some assumptions about the expected HTML structure Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Created attachment 58848 [details] [review] [SIGNED-OFF] Bug 17817: Fix cloning subfields using select2 Based on Jonathan's patch (the DO NOT PUSH one), I put together this fix. What was changed is that select2 is reinitialized only after the cloned element has been appended to the DOM (so that select2 can correctly calculate the field's width). Also, I changed the selectors that searched for the line divs (for reordering) and for the subfield's input element (for erasing the field's value) to be more specific, since select2 introduced divs that broke some assumptions about the expected HTML structure Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Created attachment 58849 [details] [review] [SIGNED-OFF] Bug 17817: (Follow up) Fix reordering subfields issues Authority controlled subfields have invisible divs which produced a strange behavior when reordering (multiple clicks were needed to push a subfield up over an authority controlled subfield) Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Created attachment 58863 [details] [review] Bug 17817: Fix cloning subfields using select2 Based on Jonathan's patch (the DO NOT PUSH one), I put together this fix. What was changed is that select2 is reinitialized only after the cloned element has been appended to the DOM (so that select2 can correctly calculate the field's width). Also, I changed the selectors that searched for the line divs (for reordering) and for the subfield's input element (for erasing the field's value) to be more specific, since select2 introduced divs that broke some assumptions about the expected HTML structure Signed-off-by: Josef Moravec <josef.moravec@gmail.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> I confirm that these 2 patches fix the add item and mod biblio views as well as the batch item modification tools.
Created attachment 58864 [details] [review] Bug 17817: (Follow up) Fix reordering subfields issues Authority controlled subfields have invisible divs which produced a strange behavior when reordering (multiple clicks were needed to push a subfield up over an authority controlled subfield) Signed-off-by: Josef Moravec <josef.moravec@gmail.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Great job Patricio! Do not forget to add a test plan, for you next patches :)
Pushed to master for 17.05, thanks Patricia!
Apologies, thanks Patricio!
(In reply to Jonathan Druart from comment #23) > Great job Patricio! > Do not forget to add a test plan, for you next patches :) Thanks Jonathan :) . I'm glad to help. I'll try to put together the steps needed to test the changes and won't forget to add them next time.
(In reply to Kyle M Hall from comment #24) > Pushed to master for 17.05, thanks Patricia! (In reply to Kyle M Hall from comment #25) > Apologies, thanks Patricio! Thanks Kyle! No problem :)
These patches have been pushed to 16.11.x and will be in 16.11.02.
Blocked by enhancement, skipping for 16.05.x
*** Bug 17818 has been marked as a duplicate of this bug. ***
In the same bug there is another problem. When we try to add an authority in field 701 702, that is, where a field with authorized value exists, it does not add the authority that exists, it creates another authority id.
(In reply to angelo from comment #31) > In the same bug there is another problem. When we try to add an authority in > field 701 702, that is, where a field with authorized value exists, it does > not add the authority that exists, it creates another authority id. Please open a new bug report, it's a completely different problem?
s/?//