Send Koha-devel mailing list submissions to
    koha-devel@lists.koha-community.org

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
or, via email, send a message with subject or body 'help' to
    koha-devel-request@lists.koha-community.org

You can reach the person managing the list at
    koha-devel-owner@lists.koha-community.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Koha-devel digest..."


Today's Topics:

1. Need help with bug 26247 (Mark Alexander)
2. Re: Need help with bug 26247 (Michael Hafen (TECH))
3. Re: Need help with bug 26247 (Mark Alexander)


----------------------------------------------------------------------

Message: 1
Date: Mon, 02 May 2022 16:18:35 -0400
From: Mark Alexander <marka@pobox.com>
To: koha-devel <koha-devel@lists.koha-community.org>
Subject: [Koha-devel] Need help with bug 26247
Message-ID: <1651521990-sup-1319@t450s>
Content-Type: text/plain; charset=UTF-8

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


------------------------------

Message: 2
Date: Mon, 2 May 2022 15:12:41 -0600
From: "Michael Hafen (TECH)" <michael.hafen@washk12.org>
To: Mark Alexander <marka@pobox.com>
Cc: koha-devel <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] Need help with bug 26247
Message-ID:
    <CAAh7UdkT0HFi22ysFUS98V43iQsf8V8rK3hu9eb_NNUrnXY99Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220502/b95d0bab/attachment-0001.htm>

------------------------------

Message: 3
Date: Mon, 02 May 2022 20:17:52 -0400
From: Mark Alexander <marka@pobox.com>
To: koha-devel <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] Need help with bug 26247
Message-ID: <1651535140-sup-833@t450s>
Content-Type: text/plain; charset=UTF-8

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


------------------------------

Subject: Digest Footer

_______________________________________________
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/


------------------------------

End of Koha-devel Digest, Vol 198, Issue 1
******************************************