Need help with bug 26247
It used to be that at our library, we could check the status of a pile of books by using "Search the catalog" in the search box at the top of most pages. You could just keep scanning barcodes without having to do anything with the mouse or keyboard. This is very useful when you have a library with volunteers who are not very careful about checking in returned books. Then at some point, Koha 20.05 broke this functionality by always populating the search box with the last barcode scanned. Now you have to manually erase everything in the search box before scanning each book. We are now using 20.05.15, but the same bug exists in 21.11.02. I have been struggling for several days with trying to find a temporary fix for this problem. There was a suggested quick fix in Javascript at the end of bug 26247, but that didn't work for me, as I mentioned in a comment on that bug. Then I tried hacking the function keep_text in staff-global.js, because in bug 19046, which was supposedly the source of the problem, keep_text seemed like where the action was taking place. But hacking that function had no effect; in fact, when I set a breakpoint in that function in Firefox, it was never hit. I think this is because keep_text is only triggered by a mouse click event, not by a form reload. So now I've been trying to find out where the search box is getting filled with the last search string after you hit the Search button. I am not super-familiar with the Koha code, but I'm comfortable hacking on it if I know where to look. Any help with finding the source of the search box autofill would be greatly appreciated. -- Maybe I'm lucky to be going so slowly because I may be going in the wrong direction. --Ashleigh Brilliant
You mentioned bug 26247. There was a follow up comment there after your that looks like it would work to me. ( i.e. putting : $(document).ready(function() { $("#header_search #catalog_search input[name='q']").val(""); }); in the IntranetUserJS system preference ) Having looked at the template files, and the perl file, I found: /catalogue/search.pl: 379 if ($operands[0] && !$operands[1]) { 380 my $ms_query = $operands[0]; 381 $ms_query =~ s/ #\S+//; 382 $template->param(ms_value => $ms_query); 383 } That puts the simple search query into a template variable, which then gets put in the 'Search the Catalog' quick search input field via the 'value' attribute. That's probably where you want to go hacking. On Mon, May 2, 2022 at 2:18 PM Mark Alexander <marka@pobox.com> wrote:
It used to be that at our library, we could check the status of a pile of books by using "Search the catalog" in the search box at the top of most pages. You could just keep scanning barcodes without having to do anything with the mouse or keyboard. This is very useful when you have a library with volunteers who are not very careful about checking in returned books.
Then at some point, Koha 20.05 broke this functionality by always populating the search box with the last barcode scanned. Now you have to manually erase everything in the search box before scanning each book. We are now using 20.05.15, but the same bug exists in 21.11.02.
I have been struggling for several days with trying to find a temporary fix for this problem. There was a suggested quick fix in Javascript at the end of bug 26247, but that didn't work for me, as I mentioned in a comment on that bug.
Then I tried hacking the function keep_text in staff-global.js, because in bug 19046, which was supposedly the source of the problem, keep_text seemed like where the action was taking place. But hacking that function had no effect; in fact, when I set a breakpoint in that function in Firefox, it was never hit. I think this is because keep_text is only triggered by a mouse click event, not by a form reload.
So now I've been trying to find out where the search box is getting filled with the last search string after you hit the Search button. I am not super-familiar with the Koha code, but I'm comfortable hacking on it if I know where to look. Any help with finding the source of the search box autofill would be greatly appreciated.
-- Maybe I'm lucky to be going so slowly because I may be going in the wrong direction. --Ashleigh Brilliant _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
-- Michael Hafen Washington County School District Technology Department Systems Analyst
Excerpts from Michael Hafen (TECH)'s message of 2022-05-02 15:12:41 -0600:
$(document).ready(function() { $("#header_search #catalog_search input[name='q']").val(""); });
in the IntranetUserJS system preference )
This doesn't work. The barcode is still in the searchbox after submitting the form.
/catalogue/search.pl: 379 if ($operands[0] && !$operands[1]) { 380 my $ms_query = $operands[0]; 381 $ms_query =~ s/ #\S+//; 382 $template->param(ms_value => $ms_query); 383 }
Yes, I discovered this function already and tried hacking it in various ways. For example, replacing the first line with this: if (0 && $operands[0] && !$operands[1]) { Or changing the name of the parameter being passed to the template with something bogus: $template->param(ms_value_bogus => $ms_query); Nothing works. Just to be safe, I tried rebooting the VM after each change to make sure that all caches were cleared. Something else is filling in the searchbox, and it's driving me crazy trying to figure it out. I think the next step is to try to figure out exactly which change caused the problem, perhaps using docker. -- I need more time and I probably always will. --Ashleigh Brilliant
On Mon, May 2, 2022 at 6:18 PM Mark Alexander <marka@pobox.com> wrote:
Excerpts from Michael Hafen (TECH)'s message of 2022-05-02 15:12:41 -0600:
$(document).ready(function() { $("#header_search #catalog_search input[name='q']").val(""); });
in the IntranetUserJS system preference )
This doesn't work. The barcode is still in the searchbox after submitting the form.
That's weird. I have a vm running master as a dev install. I just tried that bit of javascript in the syspref, and it worked for me. How frustrating. Have you tried a different browser? -- Michael Hafen Washington County School District Technology Department Systems Analyst
After spending time in the browser debugger, I have more information. 1. The keep_text function in staff-global.js only gets called when you click on the "Check out", "Check in", or "Renew" links under the search box; that is, when you change the type of search you desire. But that is not the situation I'm talking about in our library's workflow. We select "Search the catalog" and then repeatedly enter barcodes in the search box. In that situation, keep_text never gets called, and the last search string (the last barcode) persists and has to be erased manually after each submit. 2. I have disabled the code in search.pl that fills in the search box by this trick: # if a simple search, display the value in the search box if (0 && $operands[0] && !$operands[1]) { But it has no effect. 3. The Javascript snippet that was suggested for IntranetUserJS does in fact get called. I verified this by modifying it to put a "bogus" string in the search box, as follows: $(document).ready(function() { $("#header_search #catalog_search input[name='q']").val("bogus"); }); When I put a breakpoint at this function, then step over it, I see the string "bogus" put into the search box as expected. But then when I continue execution, the original search string (a book barcode) is put into the search box, overwriting "bogus". This is the mystery I am trying to solve. I have tried setting a "break on attribute modifications" breakpoint on the text input field but it never gets hit. -- I am currently going through a difficult transition period called "Life". --Ashleigh Brilliant
Hi, I propose a really quick-fix directly on templates in comment : https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26247#c29 Best regards, Le 04/05/2022 à 02:10, Mark Alexander a écrit :
After spending time in the browser debugger, I have more information.
1. The keep_text function in staff-global.js only gets called when you click on the "Check out", "Check in", or "Renew" links under the search box; that is, when you change the type of search you desire. But that is not the situation I'm talking about in our library's workflow. We select "Search the catalog" and then repeatedly enter barcodes in the search box. In that situation, keep_text never gets called, and the last search string (the last barcode) persists and has to be erased manually after each submit.
2. I have disabled the code in search.pl that fills in the search box by this trick:
# if a simple search, display the value in the search box if (0 && $operands[0] && !$operands[1]) {
But it has no effect.
3. The Javascript snippet that was suggested for IntranetUserJS does in fact get called. I verified this by modifying it to put a "bogus" string in the search box, as follows:
$(document).ready(function() { $("#header_search #catalog_search input[name='q']").val("bogus"); });
When I put a breakpoint at this function, then step over it, I see the string "bogus" put into the search box as expected. But then when I continue execution, the original search string (a book barcode) is put into the search box, overwriting "bogus". This is the mystery I am trying to solve.
I have tried setting a "break on attribute modifications" breakpoint on the text input field but it never gets hit.
-- Fridolin SOMERS <fridolin.somers@biblibre.com> Software and system maintainer 🦄 BibLibre, France
participants (3)
-
Fridolin SOMERS -
Mark Alexander -
Michael Hafen (TECH)