Can confirm that this also occurs on master (using Firefox, Google Chrome and Chromium on Ubuntu 18.04). *** Bug 27838 has been marked as a duplicate of this bug. *** (In reply to Jonathan Druart from comment #1 on Bug 27838) function SetSubfieldNumber(subfield_name, nb) { > > And I bet the culprit is: > 52 var field_start = > whichfield.parentNode.parentNode.parentNode.parentNode; ...which is exactly what makes that kind of selector so fragile!! Created attachment 117544 [details] [review] Bug 27737: Tag editor for authority lookup broken in authority editor This patch corrects the selector used for targeting the correct fields during an authority linking operation. To test, apply the patch and go to Authorities in the staff client. - Create or edit an authority record. - Switch to tab 5 and if necessary click one of the tag names (e.g. "SEE ALSO FROM TRACING--PERSONAL NAME") to expand the subfields. - Click the "..." plugin link next to subfield a ("Personal name" in this example). - In the popup window, search for an authority record. - Click "Choose" next to one of the results. - The popup window should close and the authority editor should contain data from the record you chose, including a value in $9 and $a. - Test with various records to confirm that data in other fields is copied correctly, for instanct $d, dates associated with a name, $t title of a work. Created attachment 117545 [details] [review] Bug 27737: Tag editor for authority lookup broken in authority editor This patch corrects the selector used for targeting the correct fields during an authority linking operation. To test, apply the patch and go to Authorities in the staff client. - Create or edit an authority record. - Switch to tab 5 and if necessary click one of the tag names (e.g. "SEE ALSO FROM TRACING--PERSONAL NAME") to expand the subfields. - Click the "..." plugin link next to subfield a ("Personal name" in this example). - In the popup window, search for an authority record. - Click "Choose" next to one of the results. - The popup window should close and the authority editor should contain data from the record you chose, including a value in $9 and $a. - Test with various records to confirm that data in other fields is copied correctly, for instanct $d, dates associated with a name, $t title of a work. Signed-off-by: David Nind <david@davidnind.com> Sorry Owen, changing to failed QA. I went back and checked to make sure that adding or editing using authority lookup still works for standard MARC editing, such as 100. Before the patch is applied this works. After the patch is applied and when editing a record, you get a "spinning wheel" when you click on the choose button. 8-( I confirm the bug for Koha 20.11 on Ubuntu 20.04.1. For us, it is a critical error, almost a game stopper. I tried to reflect it by my vote above. We are thinking about downgrading to Koha 20.05. We are not sure, how difficult it is. We would be grateful for an advice or an opinion. The question is: What to expect about the time needed for the "trivial patch" expected above. We may be able to provide some small money for the solution. What are the other ways to support the resolution of this bug? Even the $a is not copied, the catalogued can copy & paste manually to the proper bibliographic tag. Do not worry, just tell the catalogues that before select the authority, copy and paste the mai entry and paste. Upping severity. Created attachment 117860 [details]
Before workaround suggested by Hugo
Created attachment 117862 [details]
After workaround suggested by Hugo
Thank you, Hugo. I twice coppied (Čejka and Dostálek) 100 a ---> 500 a and 100 d ---> 500 d And it seems to work. See https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=117860 https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=117862 (In reply to Primo Kohák from comment #7) > I confirm the bug for Koha 20.11 on Ubuntu 20.04.1. For us, it is a critical > error, almost a game stopper. I tried to reflect it by my vote above. We are > thinking about downgrading to Koha 20.05. We are not sure, how difficult it > is. We would be grateful for an advice or an opinion. The question is: What > to expect about the time needed for the "trivial patch" expected above. We > may be able to provide some small money for the solution. What are the other > ways to support the resolution of this bug? This is likely to get into the next maintenance release - I would strongly recommend against trying a downgrade. There is no process for this and you'd have to manually reverse database changes etc. - dangerous. Easier to use the patch from here and maybe implement that in your installation. Created attachment 117872 [details] [review] Bug 27737: Tag editor for authority lookup broken in authority editor This patch changes the markup structure for the authorities editor so that it better matches that of the basic bibliographic record editor. This allows the authority-linking JavaScript to correctly target fields on both pages. To test, apply the patch and go to Authorities in the staff client. - Create or edit an authority record. - Switch to tab 5 and if necessary click one of the tag names (e.g. "SEE ALSO FROM TRACING--PERSONAL NAME") to expand the subfields. - Click the "..." plugin link next to subfield a ("Personal name" in this example). - In the popup window, search for an authority record. - Click "Choose" next to one of the results. - The popup window should close and the authority editor should contain data from the record you chose, including a value in $9 and $a. - Test with various records to confirm that data in other fields is copied correctly, for instanct $d, dates associated with a name, $t title of a work. - Test other JavaScript-driven interactions in the editor: - Duplicate repeatable tag - Remove repeatable tag - Empty tag - Reorder sortable tags (e.g. multiple 500 tags) - Reorder sortable subfields - Duplicate repeatable subfield - Remove repeatable subfield - Empty repeatable subfield That restores all the functionality, but the CSS changes drop the specificity of the rules that were #cat_addbiblio .whatever, so you lose the flex and width: 100% on the inputs and wind up with 50 or 60em, depending on the min-width. (In reply to Katrin Fischer from comment #13) > I would strongly > recommend against trying a downgrade. > Easier to use > the patch from here and maybe implement that in your installation. Thank you for your advice. We shall follow it. (In reply to Owen Leonard from comment #14) > Created attachment 117872 [details] [review] Thank you for the patch. (In reply to Phil Ringnalda from comment #15) > That restores all the functionality, but the CSS changes drop the > specificity of the rules that were #cat_addbiblio .whatever, so you lose the > flex and width: 100% on the inputs and wind up with 50 or 60em, depending on > the min-width. Not sure, what that means for us. Perhaps, I shall wait a little bit with the implementation of the patch. It will be my first time doing a patch anyway. I will start with the man page (https://man.archlinux.org/man/patch.1). Created attachment 117883 [details] Screenshot of input fields overlaying field descriptions I tested the linking to authorities in: - authority editor - normal cataloging editor - advanced marc editor (rancor) (still broken, see: bug 11299) As this fixes functionality, I am going to sign off, but there is still a graphical glitch where the input fields overlay the field descriptions and the copy/delete icons are too far away at the end of the fields (see screenshot) Created attachment 117884 [details] [review] Bug 27737: Tag editor for authority lookup broken in authority editor This patch changes the markup structure for the authorities editor so that it better matches that of the basic bibliographic record editor. This allows the authority-linking JavaScript to correctly target fields on both pages. To test, apply the patch and go to Authorities in the staff client. - Create or edit an authority record. - Switch to tab 5 and if necessary click one of the tag names (e.g. "SEE ALSO FROM TRACING--PERSONAL NAME") to expand the subfields. - Click the "..." plugin link next to subfield a ("Personal name" in this example). - In the popup window, search for an authority record. - Click "Choose" next to one of the results. - The popup window should close and the authority editor should contain data from the record you chose, including a value in $9 and $a. - Test with various records to confirm that data in other fields is copied correctly, for instanct $d, dates associated with a name, $t title of a work. - Test other JavaScript-driven interactions in the editor: - Duplicate repeatable tag - Remove repeatable tag - Empty tag - Reorder sortable tags (e.g. multiple 500 tags) - Reorder sortable subfields - Duplicate repeatable subfield - Remove repeatable subfield - Empty repeatable subfield Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> https://bugs.koha-community.org/show_bug.cgi?id=22737 Created attachment 117952 [details] [review] Bug 27737: (follow-up) Minimal CSS changes to avoid regressions To keep the specificity of the rules we want to have apply to both the biblio editor and also the authorities editor, we need to add the ID for the authorities editor, rather than remove the ID for the biblio editor. Also, the removal of the selectors for #authoritiestabs descendents was regressing the display of authority record details, which is where that plural authoritiestabs element lives. Test plan: 1. With neither patch from this bug applied, Cataloging - New record - Default framework. 2. Shrink and widen your browser window, noticing how the input fields flex to remain the full width, keeping the controls to duplicate and delete a subfield out directly to the right of the input. 3. Authorities - search for Perl (or any term that will match a record), click the linked authority term to open the Authority detail display 4. Note how the field number, field description, and subfield descriptions are all different colors, and subfield codes are on the same line as the subfield contents. 5. Apply both patches from this bug. 6. Cataloging - New record - Default framework 7. Verify that the input fields still behave the same as you widen and shrink your browser window 8. Authorities - New authority - Chronological Term 9. Verify that the input fields now behave like the ones in the biblio editor, shrinking and widening to fill the width of the page, keeping the controls to duplicate and delete subfields immediately to the right of the field 10. Authorities - search for Perl, click the linked authority term to open the Authority detail display 11. Verify that the tag number, field description and subfield descriptions are still properly colored and subfield codes are still on the same line as the subfield contents. Can we get a signoff on this one please? Created attachment 118115 [details]
Screenshot of overlayed field descriptions by input fields
It seems like the problem of input fields overlaying the field descriptions is still here, see the PNG attachment: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=118115 Though the copy/delete icons are displayed more correctly now. Created attachment 118116 [details] [review] Bug 27737: Tag editor for authority lookup broken in authority editor This patch changes the markup structure for the authorities editor so that it better matches that of the basic bibliographic record editor. This allows the authority-linking JavaScript to correctly target fields on both pages. To test, apply the patch and go to Authorities in the staff client. - Create or edit an authority record. - Switch to tab 5 and if necessary click one of the tag names (e.g. "SEE ALSO FROM TRACING--PERSONAL NAME") to expand the subfields. - Click the "..." plugin link next to subfield a ("Personal name" in this example). - In the popup window, search for an authority record. - Click "Choose" next to one of the results. - The popup window should close and the authority editor should contain data from the record you chose, including a value in $9 and $a. - Test with various records to confirm that data in other fields is copied correctly, for instanct $d, dates associated with a name, $t title of a work. - Test other JavaScript-driven interactions in the editor: - Duplicate repeatable tag - Remove repeatable tag - Empty tag - Reorder sortable tags (e.g. multiple 500 tags) - Reorder sortable subfields - Duplicate repeatable subfield - Remove repeatable subfield - Empty repeatable subfield Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: David Nind <david@davidnind.com> Created attachment 118117 [details] [review] Bug 27737: (follow-up) Minimal CSS changes to avoid regressions To keep the specificity of the rules we want to have apply to both the biblio editor and also the authorities editor, we need to add the ID for the authorities editor, rather than remove the ID for the biblio editor. Also, the removal of the selectors for #authoritiestabs descendents was regressing the display of authority record details, which is where that plural authoritiestabs element lives. Test plan: 1. With neither patch from this bug applied, Cataloging - New record - Default framework. 2. Shrink and widen your browser window, noticing how the input fields flex to remain the full width, keeping the controls to duplicate and delete a subfield out directly to the right of the input. 3. Authorities - search for Perl (or any term that will match a record), click the linked authority term to open the Authority detail display 4. Note how the field number, field description, and subfield descriptions are all different colors, and subfield codes are on the same line as the subfield contents. 5. Apply both patches from this bug. 6. Cataloging - New record - Default framework 7. Verify that the input fields still behave the same as you widen and shrink your browser window 8. Authorities - New authority - Chronological Term 9. Verify that the input fields now behave like the ones in the biblio editor, shrinking and widening to fill the width of the page, keeping the controls to duplicate and delete subfields immediately to the right of the field 10. Authorities - search for Perl, click the linked authority term to open the Authority detail display 11. Verify that the tag number, field description and subfield descriptions are still properly colored and subfield codes are still on the same line as the subfield contents. Signed-off-by: David Nind <david@davidnind.com> (In reply to Peter Vashchuk from comment #22) > It seems like the problem of input fields overlaying the field descriptions > is still here, see the PNG attachment: > https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=118115 > > Though the copy/delete icons are displayed more correctly now. What I am seeing on master+those 2 patches: https://snipboard.io/sjlpMQ.jpg Looks nice. Created attachment 118174 [details] [review] Bug 27737: (follow-up) Minimal CSS changes to avoid regressions To keep the specificity of the rules we want to have apply to both the biblio editor and also the authorities editor, we need to add the ID for the authorities editor, rather than remove the ID for the biblio editor. Also, the removal of the selectors for #authoritiestabs descendents was regressing the display of authority record details, which is where that plural authoritiestabs element lives. Test plan: 1. With neither patch from this bug applied, Cataloging - New record - Default framework. 2. Shrink and widen your browser window, noticing how the input fields flex to remain the full width, keeping the controls to duplicate and delete a subfield out directly to the right of the input. 3. Authorities - search for Perl (or any term that will match a record), click the linked authority term to open the Authority detail display 4. Note how the field number, field description, and subfield descriptions are all different colors, and subfield codes are on the same line as the subfield contents. 5. Apply both patches from this bug. 6. Cataloging - New record - Default framework 7. Verify that the input fields still behave the same as you widen and shrink your browser window 8. Authorities - New authority - Chronological Term 9. Verify that the input fields now behave like the ones in the biblio editor, shrinking and widening to fill the width of the page, keeping the controls to duplicate and delete subfields immediately to the right of the field 10. Authorities - search for Perl, click the linked authority term to open the Authority detail display 11. Verify that the tag number, field description and subfield descriptions are still properly colored and subfield codes are still on the same line as the subfield contents. Signed-off-by: David Nind <david@davidnind.com> Trivial fixup for a copy-paste failure, missed the y on subfield_loop_mandator No idea how to produce the result in Peter's screenshot, unless it's cached HTML and uncached CSS. That appearance says that #authoritytabs .subfield_line and #authoritytabs .field_marceditor apply, but #authoritytabs .subfield label does not, implying that the <label> isn't a descendant of something class="subfield", which it used to not be, but is with the first patch here. Yep Phil, the problem was on my end. Sorry for the false alarm everyone :) Created attachment 118179 [details] [review] Bug 27737: (follow-up) Minimal CSS changes to avoid regressions To keep the specificity of the rules we want to have apply to both the biblio editor and also the authorities editor, we need to add the ID for the authorities editor, rather than remove the ID for the biblio editor. Also, the removal of the selectors for #authoritiestabs descendents was regressing the display of authority record details, which is where that plural authoritiestabs element lives. Test plan: 1. With neither patch from this bug applied, Cataloging - New record - Default framework. 2. Shrink and widen your browser window, noticing how the input fields flex to remain the full width, keeping the controls to duplicate and delete a subfield out directly to the right of the input. 3. Authorities - search for Perl (or any term that will match a record), click the linked authority term to open the Authority detail display 4. Note how the field number, field description, and subfield descriptions are all different colors, and subfield codes are on the same line as the subfield contents. 5. Apply both patches from this bug. 6. Cataloging - New record - Default framework 7. Verify that the input fields still behave the same as you widen and shrink your browser window 8. Authorities - New authority - Chronological Term 9. Verify that the input fields now behave like the ones in the biblio editor, shrinking and widening to fill the width of the page, keeping the controls to duplicate and delete subfields immediately to the right of the field 10. Authorities - search for Perl, click the linked authority term to open the Authority detail display 11. Verify that the tag number, field description and subfield descriptions are still properly colored and subfield codes are still on the same line as the subfield contents. Signed-off-by: David Nind <david@davidnind.com> Trivial fixup for a copy-paste failure, missed the y on subfield_loop_mandator Signed-off-by: Petro Vashchuk <stalkernoid@gmail.com> Created attachment 118187 [details] [review] Bug 27737: Tag editor for authority lookup broken in authority editor This patch changes the markup structure for the authorities editor so that it better matches that of the basic bibliographic record editor. This allows the authority-linking JavaScript to correctly target fields on both pages. To test, apply the patch and go to Authorities in the staff client. - Create or edit an authority record. - Switch to tab 5 and if necessary click one of the tag names (e.g. "SEE ALSO FROM TRACING--PERSONAL NAME") to expand the subfields. - Click the "..." plugin link next to subfield a ("Personal name" in this example). - In the popup window, search for an authority record. - Click "Choose" next to one of the results. - The popup window should close and the authority editor should contain data from the record you chose, including a value in $9 and $a. - Test with various records to confirm that data in other fields is copied correctly, for instanct $d, dates associated with a name, $t title of a work. - Test other JavaScript-driven interactions in the editor: - Duplicate repeatable tag - Remove repeatable tag - Empty tag - Reorder sortable tags (e.g. multiple 500 tags) - Reorder sortable subfields - Duplicate repeatable subfield - Remove repeatable subfield - Empty repeatable subfield Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> https://bugs.koha-community.org/show_bug.cgi?id=22737 Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Created attachment 118188 [details] [review] Bug 27737: (follow-up) Minimal CSS changes to avoid regressions To keep the specificity of the rules we want to have apply to both the biblio editor and also the authorities editor, we need to add the ID for the authorities editor, rather than remove the ID for the biblio editor. Also, the removal of the selectors for #authoritiestabs descendents was regressing the display of authority record details, which is where that plural authoritiestabs element lives. Test plan: 1. With neither patch from this bug applied, Cataloging - New record - Default framework. 2. Shrink and widen your browser window, noticing how the input fields flex to remain the full width, keeping the controls to duplicate and delete a subfield out directly to the right of the input. 3. Authorities - search for Perl (or any term that will match a record), click the linked authority term to open the Authority detail display 4. Note how the field number, field description, and subfield descriptions are all different colors, and subfield codes are on the same line as the subfield contents. 5. Apply both patches from this bug. 6. Cataloging - New record - Default framework 7. Verify that the input fields still behave the same as you widen and shrink your browser window 8. Authorities - New authority - Chronological Term 9. Verify that the input fields now behave like the ones in the biblio editor, shrinking and widening to fill the width of the page, keeping the controls to duplicate and delete subfields immediately to the right of the field 10. Authorities - search for Perl, click the linked authority term to open the Authority detail display 11. Verify that the tag number, field description and subfield descriptions are still properly colored and subfield codes are still on the same line as the subfield contents. Signed-off-by: David Nind <david@davidnind.com> Trivial fixup for a copy-paste failure, missed the y on subfield_loop_mandator Signed-off-by: Petro Vashchuk <stalkernoid@gmail.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Pushed to master for 21.05, thanks to everybody involved! Pushed to 20.11.x for 20.11.04 Missing dependency, not backported to 20.05 |
Steps to reproduce: 1. Authorities, search for any authority ("Perl" will work fine in kohadev), Actions - Edit 2. Switch to tab 5, click "SEE ALSO FROM TRACING--PERSONAL NAME" to expand subfields 3. In subfield a, type smith and click the ... at the end of the field to open authority search 4. Search and choose any of the results Expect result: Subfield a contains the name from the authority you chose, subfield 9 contains the authid Actual result: Subfield a still contains just the smith that you typed, though subfield 9 does contain the authid The bib editor does work correctly. Bisected to 579608808c4ec81f469e4c48627525d17a16194d from bug 22399