<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body>A new request with request id 10204 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is : <br><br>Title : Koha-devel Digest, Vol 198, Issue 1<br>Category : <br>Description : <div>Send Koha-devel mailing list submissions to<br> koha-devel@lists.koha-community.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>or, via email, send a message with subject or body 'help' to<br> koha-devel-request@lists.koha-community.org<br><br>You can reach the person managing the list at<br> koha-devel-owner@lists.koha-community.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of Koha-devel digest..."<br><br><br>Today's Topics:<br><br> 1. Need help with bug 26247 (Mark Alexander)<br> 2. Re: Need help with bug 26247 (Michael Hafen (TECH))<br> 3. Re: Need help with bug 26247 (Mark Alexander)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Mon, 02 May 2022 16:18:35 -0400<br>From: Mark Alexander <marka@pobox.com><br>To: koha-devel <koha-devel@lists.koha-community.org><br>Subject: [Koha-devel] Need help with bug 26247<br>Message-ID: <1651521990-sup-1319@t450s><br>Content-Type: text/plain; charset=UTF-8<br><br>It used to be that at our library, we could check the status of a pile<br>of books by using "Search the catalog" in the search box at the top of<br>most pages. You could just keep scanning barcodes without having to<br>do anything with the mouse or keyboard. This is very useful when you<br>have a library with volunteers who are not very careful about checking<br>in returned books.<br><br>Then at some point, Koha 20.05 broke this functionality by always<br>populating the search box with the last barcode scanned. Now you have<br>to manually erase everything in the search box before scanning each<br>book. We are now using 20.05.15, but the same bug exists in 21.11.02.<br><br>I have been struggling for several days with trying to find a<br>temporary fix for this problem. There was a suggested quick fix in<br>Javascript at the end of bug 26247, but that didn't work for me, as I<br>mentioned in a comment on that bug.<br><br>Then I tried hacking the function keep_text in staff-global.js,<br>because in bug 19046, which was supposedly the source of the problem,<br>keep_text seemed like where the action was taking place. But hacking<br>that function had no effect; in fact, when I set a breakpoint in that<br>function in Firefox, it was never hit. I think this is because<br>keep_text is only triggered by a mouse click event, not by a form<br>reload.<br><br>So now I've been trying to find out where the search box is getting<br>filled with the last search string after you hit the Search button. I<br>am not super-familiar with the Koha code, but I'm comfortable hacking<br>on it if I know where to look. Any help with finding the source of<br>the search box autofill would be greatly appreciated.<br><br>-- <br>Maybe I'm lucky to be going so slowly because I may<br>be going in the wrong direction. --Ashleigh Brilliant<br><br><br>------------------------------<br><br>Message: 2<br>Date: Mon, 2 May 2022 15:12:41 -0600<br>From: "Michael Hafen (TECH)" <michael.hafen@washk12.org><br>To: Mark Alexander <marka@pobox.com><br>Cc: koha-devel <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] Need help with bug 26247<br>Message-ID:<br> <CAAh7UdkT0HFi22ysFUS98V43iQsf8V8rK3hu9eb_NNUrnXY99Q@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>You mentioned bug 26247. There was a follow up comment there after your<br>that looks like it would work to me.<br>( i.e. putting :<br><br>$(document).ready(function() {<br> $("#header_search #catalog_search input[name='q']").val("");<br>});<br><br>in the IntranetUserJS system preference )<br><br><br>Having looked at the template files, and the perl file, I found:<br><br>/catalogue/search.pl:<br> 379 if ($operands[0] && !$operands[1]) {<br> 380 my $ms_query = $operands[0];<br> 381 $ms_query =~ s/ #\S+//;<br> 382 $template->param(ms_value => $ms_query);<br> 383 }<br><br>That puts the simple search query into a template variable, which then gets<br>put in the 'Search the Catalog' quick search input field via the 'value'<br>attribute.<br>That's probably where you want to go hacking.<br><br><br>On Mon, May 2, 2022 at 2:18 PM Mark Alexander <marka@pobox.com> wrote:<br><br>> It used to be that at our library, we could check the status of a pile<br>> of books by using "Search the catalog" in the search box at the top of<br>> most pages. You could just keep scanning barcodes without having to<br>> do anything with the mouse or keyboard. This is very useful when you<br>> have a library with volunteers who are not very careful about checking<br>> in returned books.<br>><br>> Then at some point, Koha 20.05 broke this functionality by always<br>> populating the search box with the last barcode scanned. Now you have<br>> to manually erase everything in the search box before scanning each<br>> book. We are now using 20.05.15, but the same bug exists in 21.11.02.<br>><br>> I have been struggling for several days with trying to find a<br>> temporary fix for this problem. There was a suggested quick fix in<br>> Javascript at the end of bug 26247, but that didn't work for me, as I<br>> mentioned in a comment on that bug.<br>><br>> Then I tried hacking the function keep_text in staff-global.js,<br>> because in bug 19046, which was supposedly the source of the problem,<br>> keep_text seemed like where the action was taking place. But hacking<br>> that function had no effect; in fact, when I set a breakpoint in that<br>> function in Firefox, it was never hit. I think this is because<br>> keep_text is only triggered by a mouse click event, not by a form<br>> reload.<br>><br>> So now I've been trying to find out where the search box is getting<br>> filled with the last search string after you hit the Search button. I<br>> am not super-familiar with the Koha code, but I'm comfortable hacking<br>> on it if I know where to look. Any help with finding the source of<br>> the search box autofill would be greatly appreciated.<br>><br>> --<br>> Maybe I'm lucky to be going so slowly because I may<br>> be going in the wrong direction. --Ashleigh Brilliant<br>> _______________________________________________<br>> Koha-devel mailing list<br>> Koha-devel@lists.koha-community.org<br>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>> website : https://www.koha-community.org/<br>> git : https://git.koha-community.org/<br>> bugs : https://bugs.koha-community.org/<br>><br><br><br>-- <br>Michael Hafen<br>Washington County School District Technology Department<br>Systems Analyst<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220502/b95d0bab/attachment-0001.htm><br><br>------------------------------<br><br>Message: 3<br>Date: Mon, 02 May 2022 20:17:52 -0400<br>From: Mark Alexander <marka@pobox.com><br>To: koha-devel <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] Need help with bug 26247<br>Message-ID: <1651535140-sup-833@t450s><br>Content-Type: text/plain; charset=UTF-8<br><br>Excerpts from Michael Hafen (TECH)'s message of 2022-05-02 15:12:41 -0600:<br>> $(document).ready(function() {<br>> $("#header_search #catalog_search input[name='q']").val("");<br>> });<br>> <br>> in the IntranetUserJS system preference )<br><br>This doesn't work. The barcode is still in the searchbox after<br>submitting the form.<br><br>> /catalogue/search.pl:<br>> 379 if ($operands[0] && !$operands[1]) {<br>> 380 my $ms_query = $operands[0];<br>> 381 $ms_query =~ s/ #\S+//;<br>> 382 $template->param(ms_value => $ms_query);<br>> 383 }<br><br>Yes, I discovered this function already and tried hacking it in<br>various ways. For example, replacing the first line with this:<br><br>if (0 && $operands[0] && !$operands[1]) {<br><br>Or changing the name of the parameter being passed to the template<br>with something bogus:<br><br> $template->param(ms_value_bogus => $ms_query);<br><br>Nothing works. Just to be safe, I tried rebooting the VM after<br>each change to make sure that all caches were cleared.<br><br>Something else is filling in the searchbox, and it's driving<br>me crazy trying to figure it out.<br><br>I think the next step is to try to figure out exactly which<br>change caused the problem, perhaps using docker.<br><br>-- <br>I need more time and I probably always will. --Ashleigh Brilliant<br><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>Koha-devel mailing list<br>Koha-devel@lists.koha-community.org<br>https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>website : https://www.koha-community.org/<br>git : https://git.koha-community.org/<br>bugs : https://bugs.koha-community.org/<br><br><br>------------------------------<br><br>End of Koha-devel Digest, Vol 198, Issue 1<br>******************************************<br></div><br><br>NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.<br></body></html>