<!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 10276 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 3<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. Re: Need help with bug 26247 (Mark Alexander)<br> 2. Biblio Auto-Increment location (Bruce A. Metcalf)<br> 3. Re: Biblio Auto-Increment location (Chris Cormack)<br> 4. Re: Biblio Auto-Increment location (Galen Charlton)<br> 5. Using ETag for detecting mid-air collisions when cataloguing<br> (dcook@prosentient.com.au)<br> 6. Re: Need help with bug 26247 (Fridolin SOMERS)<br> 7. Seeking signoffs for the upcoming release (Owen Leonard)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Wed, 04 May 2022 08:10:56 -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: <1651665374-sup-4550@t450s><br>Content-Type: text/plain; charset=UTF-8<br><br>After spending time in the browser debugger, I have more information.<br><br>1. The keep_text function in staff-global.js only gets called when<br>you click on the "Check out", "Check in", or "Renew" links under<br>the search box; that is, when you change the type of search you<br>desire. But that is not the situation I'm talking about in<br>our library's workflow. We select "Search the catalog" and<br>then repeatedly enter barcodes in the search box. In that situation,<br>keep_text never gets called, and the last search string (the<br>last barcode) persists and has to be erased manually after<br>each submit.<br><br>2. I have disabled the code in search.pl that fills in the search<br>box by this trick:<br><br> # if a simple search, display the value in the search box<br> if (0 && $operands[0] && !$operands[1]) {<br><br>But it has no effect.<br><br>3. The Javascript snippet that was suggested for IntranetUserJS does<br>in fact get called. I verified this by modifying it to put a "bogus"<br>string in the search box, as follows:<br><br> $(document).ready(function() {<br> $("#header_search #catalog_search input[name='q']").val("bogus");<br> });<br><br>When I put a breakpoint at this function, then step over it, I see the<br>string "bogus" put into the search box as expected. But then when I<br>continue execution, the original search string (a book barcode) is put<br>into the search box, overwriting "bogus". This is the mystery I am<br>trying to solve.<br><br>I have tried setting a "break on attribute modifications" breakpoint<br>on the text input field but it never gets hit.<br><br>-- <br>I am currently going through a difficult transition period<br>called "Life". --Ashleigh Brilliant<br><br><br>------------------------------<br><br>Message: 2<br>Date: Wed, 4 May 2022 15:18:38 -0400<br>From: "Bruce A. Metcalf" <bruce.metcalf@figzu.com><br>To: koha-devel@lists.koha-community.org<br>Subject: [Koha-devel] Biblio Auto-Increment location<br>Message-ID: <322906dd-c7d4-7aad-c05e-ade82d21dbf0@figzu.com><br>Content-Type: text/plain; charset=UTF-8; format=flowed<br><br>Greetings,<br><br>Sorry to post a support question here. No one else seems to know, but <br>many think folks here might:<br><br>Thanks to help from our library cat, a biblio number was inserted that's <br>several orders of magnitude greater than those in use. I have not found <br>a way to reset this.<br><br>It's my guess that the highest previous value is stored somewhere, and <br>incremented for each additional biblio. If someone could tell me where <br>it's stored, I could reset it to the current value and not have a huge <br>gap in the numbering.<br><br>Yes, I do appreciate that the numbers are just data-less markers, but <br>I'd sill like to fix this.<br><br>Any help most appreciated.<br><br>Regards,<br>/ Bruce /<br>Bruce A. Metcalf<br>Augustan Library<br><br><br>------------------------------<br><br>Message: 3<br>Date: Thu, 5 May 2022 08:16:28 +1200<br>From: Chris Cormack <chrisc@catalyst.net.nz><br>To: koha-devel@lists.koha-community.org<br>Subject: Re: [Koha-devel] Biblio Auto-Increment location<br>Message-ID: <783e645e-53ea-8b37-5424-fa2d4fdcfadd@catalyst.net.nz><br>Content-Type: text/plain; charset=UTF-8<br><br>Hi Bruce<br><br>There's a lot we can code around, cataloguing cats is definitely not one :)<br><br>Before you attempt the fix, please do a backup, just in case.<br><br>The good news is it is fairly simple, once you have deleted the<br>offending record, then in the database you can run<br><br>ALTER TABLE biblio AUTO_INCREMENT = new_number;<br><br> (new_number should be the current highest + 1, you can do select<br>max(biblionumber) from biblio; to find the highest)<br><br>You'll also want to fix biblioitems and biblio_metadata<br>ALTER TABLE biblioitems AUTO_INCREMENT = new_number;<br>ALTER TABLE biblio_metadata AUTO_INCREMENT = new_number;<br><br>the new number for biblioitems is max biblioitemnumber + 1<br>and the new number for biblio_metadata is id + 1<br><br>Hope that helps.<br><br>Chris<br><br>And thanks for the new marketing slogan<br><br>Koha - So simple even the library cat can catalogue<br><br>On 5/05/22 07:18, Bruce A. Metcalf wrote:<br>> Greetings,<br>> <br>> Sorry to post a support question here. No one else seems to know, but<br>> many think folks here might:<br>> <br>> Thanks to help from our library cat, a biblio number was inserted that's<br>> several orders of magnitude greater than those in use. I have not found<br>> a way to reset this.<br>> <br>> It's my guess that the highest previous value is stored somewhere, and<br>> incremented for each additional biblio. If someone could tell me where<br>> it's stored, I could reset it to the current value and not have a huge<br>> gap in the numbering.<br>> <br>> Yes, I do appreciate that the numbers are just data-less markers, but<br>> I'd sill like to fix this.<br>> <br>> Any help most appreciated.<br>> <br>> Regards,<br>> / Bruce /<br>> Bruce A. Metcalf<br>> Augustan Library<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>Message: 4<br>Date: Wed, 4 May 2022 17:21:20 -0400<br>From: Galen Charlton <gmc@equinoxoli.org><br>To: koha-devel@lists.koha-community.org<br>Subject: Re: [Koha-devel] Biblio Auto-Increment location<br>Message-ID:<br> <CAPLnt65keuBh7CUE4baAUxhs6t9_mHTCsvLYHqC6aNUBij2v0w@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi Bruce,<br><br>On Wed, May 4, 2022 at 4:16 PM Chris Cormack <chrisc@catalyst.net.nz> wrote:<br>> There's a lot we can code around, cataloguing cats is definitely not one<br>:)<br><br>Is this the (adorable) miscreant in question?<br>https://twitter.com/augustanalib/status/973622037276012545<br><br>Regards,<br><br>Galen<br>--<br>Galen Charlton<br>Implementation and IT Manager<br>Equinox Open Library Initiative<br>gmc@equinoxOLI.org<br>https://www.equinoxOLI.org<br>phone: 877-OPEN-ILS (673-6457)<br>direct: 770-709-5581<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220504/acd259ae/attachment-0001.htm><br><br>------------------------------<br><br>Message: 5<br>Date: Thu, 5 May 2022 11:55:29 +1000<br>From: <dcook@prosentient.com.au><br>To: "'Koha-devel'" <koha-devel@lists.koha-community.org><br>Subject: [Koha-devel] Using ETag for detecting mid-air collisions when<br> cataloguing<br>Message-ID: <0d1301d86023$3829b950$a87d2bf0$@prosentient.com.au><br>Content-Type: text/plain; charset="utf-8"<br><br>Hey folk,<br><br> <br><br>I'm just working on some caching for a non-Koha project, and I was just<br>thinking. maybe we could use the ETag and If-Match HTTP headers to detect<br>whether or not we've got a mid-air collision when editing bib records.<br><br> <br><br>It's not something I'd be looking to work on, but I figure it's an<br>interesting idea.<br><br> <br><br>Alternatively, one could implement their own app-based hash mechanism to do<br>the same thing. <br><br> <br><br> <br><br>David Cook<br><br>Senior Software Engineer<br><br>Prosentient Systems<br><br>Suite 7.03<br><br>6a Glen St<br><br>Milsons Point NSW 2061<br><br>Australia<br><br> <br><br>Office: 02 9212 0899<br><br>Online: 02 8005 0595<br><br> <br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220505/af57aced/attachment-0001.htm><br><br>------------------------------<br><br>Message: 6<br>Date: Wed, 4 May 2022 20:40:47 -1000<br>From: Fridolin SOMERS <fridolin.somers@biblibre.com><br>To: koha-devel@lists.koha-community.org<br>Subject: Re: [Koha-devel] Need help with bug 26247<br>Message-ID: <ac450ba0-498f-c74e-d7d7-984645c5b105@biblibre.com><br>Content-Type: text/plain; charset=UTF-8; format=flowed<br><br>Hi,<br><br>I propose a really quick-fix directly on templates in comment :<br>https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26247#c29<br><br>Best regards,<br><br>Le 04/05/2022 à 02:10, Mark Alexander a écrit :<br>> After spending time in the browser debugger, I have more information.<br>> <br>> 1. The keep_text function in staff-global.js only gets called when<br>> you click on the "Check out", "Check in", or "Renew" links under<br>> the search box; that is, when you change the type of search you<br>> desire. But that is not the situation I'm talking about in<br>> our library's workflow. We select "Search the catalog" and<br>> then repeatedly enter barcodes in the search box. In that situation,<br>> keep_text never gets called, and the last search string (the<br>> last barcode) persists and has to be erased manually after<br>> each submit.<br>> <br>> 2. I have disabled the code in search.pl that fills in the search<br>> box by this trick:<br>> <br>> # if a simple search, display the value in the search box<br>> if (0 && $operands[0] && !$operands[1]) {<br>> <br>> But it has no effect.<br>> <br>> 3. The Javascript snippet that was suggested for IntranetUserJS does<br>> in fact get called. I verified this by modifying it to put a "bogus"<br>> string in the search box, as follows:<br>> <br>> $(document).ready(function() {<br>> $("#header_search #catalog_search input[name='q']").val("bogus");<br>> });<br>> <br>> When I put a breakpoint at this function, then step over it, I see the<br>> string "bogus" put into the search box as expected. But then when I<br>> continue execution, the original search string (a book barcode) is put<br>> into the search box, overwriting "bogus". This is the mystery I am<br>> trying to solve.<br>> <br>> I have tried setting a "break on attribute modifications" breakpoint<br>> on the text input field but it never gets hit.<br>> <br><br>-- <br>Fridolin SOMERS <fridolin.somers@biblibre.com><br>Software and system maintainer 🦄<br>BibLibre, France<br><br><br>------------------------------<br><br>Message: 7<br>Date: Thu, 5 May 2022 05:15:31 -0400<br>From: Owen Leonard <oleonard@myacpl.org><br>To: Koha Devel <koha-devel@lists.koha-community.org><br>Subject: [Koha-devel] Seeking signoffs for the upcoming release<br>Message-ID:<br> <CAO4qe2M0N+P_WkD5MRvyeonDWfZDb7-v8ZuJamgTdUbRqun8ZA@mail.gmail.com><br>Content-Type: text/plain; charset="UTF-8"<br><br>Hi everyone,<br><br>I've got a few patches awaiting signoff which I'd love to see make it<br>into 22.05. They're minor issues but I think they'd be good to have:<br><br>30388 -- Fix some errors in the template for ordering from a MARC file<br>30422 -- Authorities editor update broke the feature added by Bug 20154<br>30640 -- Focus does not always move to correct search header form field<br>30673 -- Improve is_valid_date function for validating date strings<br><br>Thanks for your consideration,<br><br> Owen<br><br>-- <br>Web Developer<br>Athens County Public Libraries<br>(740) 737-6006<br>https://www.myacpl.org<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 3<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>