A new request with request id 10276 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is :

Title : Koha-devel Digest, Vol 198, Issue 3
Category :
Description :
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. Re: Need help with bug 26247 (Mark Alexander)
2. Biblio Auto-Increment location (Bruce A. Metcalf)
3. Re: Biblio Auto-Increment location (Chris Cormack)
4. Re: Biblio Auto-Increment location (Galen Charlton)
5. Using ETag for detecting mid-air collisions when cataloguing
(dcook@prosentient.com.au)
6. Re: Need help with bug 26247 (Fridolin SOMERS)
7. Seeking signoffs for the upcoming release (Owen Leonard)


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

Message: 1
Date: Wed, 04 May 2022 08:10:56 -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: <1651665374-sup-4550@t450s>
Content-Type: text/plain; charset=UTF-8

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


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

Message: 2
Date: Wed, 4 May 2022 15:18:38 -0400
From: "Bruce A. Metcalf" <bruce.metcalf@figzu.com>
To: koha-devel@lists.koha-community.org
Subject: [Koha-devel] Biblio Auto-Increment location
Message-ID: <322906dd-c7d4-7aad-c05e-ade82d21dbf0@figzu.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

Greetings,

Sorry to post a support question here. No one else seems to know, but
many think folks here might:

Thanks to help from our library cat, a biblio number was inserted that's
several orders of magnitude greater than those in use. I have not found
a way to reset this.

It's my guess that the highest previous value is stored somewhere, and
incremented for each additional biblio. If someone could tell me where
it's stored, I could reset it to the current value and not have a huge
gap in the numbering.

Yes, I do appreciate that the numbers are just data-less markers, but
I'd sill like to fix this.

Any help most appreciated.

Regards,
/ Bruce /
Bruce A. Metcalf
Augustan Library


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

Message: 3
Date: Thu, 5 May 2022 08:16:28 +1200
From: Chris Cormack <chrisc@catalyst.net.nz>
To: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] Biblio Auto-Increment location
Message-ID: <783e645e-53ea-8b37-5424-fa2d4fdcfadd@catalyst.net.nz>
Content-Type: text/plain; charset=UTF-8

Hi Bruce

There's a lot we can code around, cataloguing cats is definitely not one :)

Before you attempt the fix, please do a backup, just in case.

The good news is it is fairly simple, once you have deleted the
offending record, then in the database you can run

ALTER TABLE biblio AUTO_INCREMENT = new_number;

(new_number should be the current highest + 1, you can do select
max(biblionumber) from biblio; to find the highest)

You'll also want to fix biblioitems and biblio_metadata
ALTER TABLE biblioitems AUTO_INCREMENT = new_number;
ALTER TABLE biblio_metadata AUTO_INCREMENT = new_number;

the new number for biblioitems is max biblioitemnumber + 1
and the new number for biblio_metadata is id + 1

Hope that helps.

Chris

And thanks for the new marketing slogan

Koha - So simple even the library cat can catalogue

On 5/05/22 07:18, Bruce A. Metcalf wrote:
> Greetings,
>
> Sorry to post a support question here. No one else seems to know, but
> many think folks here might:
>
> Thanks to help from our library cat, a biblio number was inserted that's
> several orders of magnitude greater than those in use. I have not found
> a way to reset this.
>
> It's my guess that the highest previous value is stored somewhere, and
> incremented for each additional biblio. If someone could tell me where
> it's stored, I could reset it to the current value and not have a huge
> gap in the numbering.
>
> Yes, I do appreciate that the numbers are just data-less markers, but
> I'd sill like to fix this.
>
> Any help most appreciated.
>
> Regards,
> / Bruce /
> Bruce A. Metcalf
> Augustan Library
> _______________________________________________
> 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/


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

Message: 4
Date: Wed, 4 May 2022 17:21:20 -0400
From: Galen Charlton <gmc@equinoxoli.org>
To: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] Biblio Auto-Increment location
Message-ID:
    <CAPLnt65keuBh7CUE4baAUxhs6t9_mHTCsvLYHqC6aNUBij2v0w@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Bruce,

On Wed, May 4, 2022 at 4:16 PM Chris Cormack <chrisc@catalyst.net.nz> wrote:
> There's a lot we can code around, cataloguing cats is definitely not one
:)

Is this the (adorable) miscreant in question?
https://twitter.com/augustanalib/status/973622037276012545

Regards,

Galen
--
Galen Charlton
Implementation and IT Manager
Equinox Open Library Initiative
gmc@equinoxOLI.org
https://www.equinoxOLI.org
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220504/acd259ae/attachment-0001.htm>

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

Message: 5
Date: Thu, 5 May 2022 11:55:29 +1000
From: <dcook@prosentient.com.au>
To: "'Koha-devel'" <koha-devel@lists.koha-community.org>
Subject: [Koha-devel] Using ETag for detecting mid-air collisions when
    cataloguing
Message-ID: <0d1301d86023$3829b950$a87d2bf0$@prosentient.com.au>
Content-Type: text/plain; charset="utf-8"

Hey folk,



I'm just working on some caching for a non-Koha project, and I was just
thinking. maybe we could use the ETag and If-Match HTTP headers to detect
whether or not we've got a mid-air collision when editing bib records.



It's not something I'd be looking to work on, but I figure it's an
interesting idea.



Alternatively, one could implement their own app-based hash mechanism to do
the same thing.





David Cook

Senior Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia



Office: 02 9212 0899

Online: 02 8005 0595



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220505/af57aced/attachment-0001.htm>

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

Message: 6
Date: Wed, 4 May 2022 20:40:47 -1000
From: Fridolin SOMERS <fridolin.somers@biblibre.com>
To: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] Need help with bug 26247
Message-ID: <ac450ba0-498f-c74e-d7d7-984645c5b105@biblibre.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

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


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

Message: 7
Date: Thu, 5 May 2022 05:15:31 -0400
From: Owen Leonard <oleonard@myacpl.org>
To: Koha Devel <koha-devel@lists.koha-community.org>
Subject: [Koha-devel] Seeking signoffs for the upcoming release
Message-ID:
    <CAO4qe2M0N+P_WkD5MRvyeonDWfZDb7-v8ZuJamgTdUbRqun8ZA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

Hi everyone,

I've got a few patches awaiting signoff which I'd love to see make it
into 22.05. They're minor issues but I think they'd be good to have:

30388 -- Fix some errors in the template for ordering from a MARC file
30422 -- Authorities editor update broke the feature added by Bug 20154
30640 -- Focus does not always move to correct search header form field
30673 -- Improve is_valid_date function for validating date strings

Thanks for your consideration,

Owen

--
Web Developer
Athens County Public Libraries
(740) 737-6006
https://www.myacpl.org


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

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 3
******************************************


NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.