A new request with request id 6959 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is :
Title : Koha-devel Digest, Vol 205, Issue 11
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: Fundamental flaw in Koha REST API (David Cook)
2. Re: Fundamental flaw in Koha REST API (David Cook)
3. Maximum execution time for background jobs? (David Cook)
----------------------------------------------------------------------
Message: 1
Date: Tue, 6 Dec 2022 11:30:46 +1100
From: "David Cook" <dcook@prosentient.com.au>
To: "'Tomas Cohen Arazi'" <tomascohen@gmail.com>, "'Galen Charlton'"
<gmc@equinoxoli.org>
Cc: "'koha-devel'" <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] Fundamental flaw in Koha REST API
Message-ID: <082501d9090a$00e0b670$02a22350$@prosentient.com.au>
Content-Type: text/plain; charset="utf-8"
Perhaps Bug 30165 allowing multiple “q” parameters would provide an alternative as well?
In the DataTables, it looks like it’s used for receiving acquisitions and something with POS registers.
In master, the acquisitions issue is solved by turning off that option switch. (Although in older versions of Koha the Orders route doesn’t seem able to handle the UTF-8 encoded characters.)
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
From: Tomas Cohen Arazi <tomascohen@gmail.com>
Sent: Tuesday, 6 December 2022 11:24 AM
To: Galen Charlton <gmc@equinoxoli.org>
Cc: David Cook <dcook@prosentient.com.au>; koha-devel <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] Fundamental flaw in Koha REST API
I recall we used the header at some point, to keep the base query clean when adding new filters.
The only alternative is forcing the use of some form of ascii encoding (base64?) But I agree we should better deprecate it.
It's use in the codebase on DT is tied to an option switch and probably not used
El lun, 5 dic 2022 20:08, Galen Charlton <gmc@equinoxoli.org <mailto:gmc@equinoxoli.org> > escribió:
Hi,
On Mon, Dec 5, 2022 at 5:40 PM David Cook <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > wrote:
> At the moment, it’s not widely used by Koha itself, so I don’t think
> it will be hard to remove from Koha, but any third-party integrations
> would need to refactor to use a different option.
This might not be a huge factor, though of course removing that header
should go through a deprecation procedure.
Specifically, upon skimming the results of a GitHub search of
"x-koha-query", the only uses I found outside of Koha itself were in
plugins published by a couple active community members.
Regards,
Galen
--
Galen Charlton
Implementation and IT Manager
Equinox Open Library Initiative
gmc@equinoxOLI.org <mailto:gmc@equinoxOLI.org>
https://www.equinoxOLI.org
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org <mailto: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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20221206/2f29dce5/attachment-0001.htm>
------------------------------
Message: 2
Date: Tue, 6 Dec 2022 11:33:03 +1100
From: "David Cook" <dcook@prosentient.com.au>
To: "'Tomas Cohen Arazi'" <tomascohen@gmail.com>, "'Galen Charlton'"
<gmc@equinoxoli.org>
Cc: "'koha-devel'" <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] Fundamental flaw in Koha REST API
Message-ID: <082a01d9090a$4d79a140$e86ce3c0$@prosentient.com.au>
Content-Type: text/plain; charset="utf-8"
Btw looks like Bug 30165 is what resolves the UTF-8 issue for the orders route…
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
From: David Cook <dcook@prosentient.com.au>
Sent: Tuesday, 6 December 2022 11:31 AM
To: 'Tomas Cohen Arazi' <tomascohen@gmail.com>; 'Galen Charlton' <gmc@equinoxoli.org>
Cc: 'koha-devel' <koha-devel@lists.koha-community.org>
Subject: RE: [Koha-devel] Fundamental flaw in Koha REST API
Perhaps Bug 30165 allowing multiple “q” parameters would provide an alternative as well?
In the DataTables, it looks like it’s used for receiving acquisitions and something with POS registers.
In master, the acquisitions issue is solved by turning off that option switch. (Although in older versions of Koha the Orders route doesn’t seem able to handle the UTF-8 encoded characters.)
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
From: Tomas Cohen Arazi <tomascohen@gmail.com <mailto:tomascohen@gmail.com> >
Sent: Tuesday, 6 December 2022 11:24 AM
To: Galen Charlton <gmc@equinoxoli.org <mailto:gmc@equinoxoli.org> >
Cc: David Cook <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> >; koha-devel <koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> >
Subject: Re: [Koha-devel] Fundamental flaw in Koha REST API
I recall we used the header at some point, to keep the base query clean when adding new filters.
The only alternative is forcing the use of some form of ascii encoding (base64?) But I agree we should better deprecate it.
It's use in the codebase on DT is tied to an option switch and probably not used
El lun, 5 dic 2022 20:08, Galen Charlton <gmc@equinoxoli.org <mailto:gmc@equinoxoli.org> > escribió:
Hi,
On Mon, Dec 5, 2022 at 5:40 PM David Cook <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > wrote:
> At the moment, it’s not widely used by Koha itself, so I don’t think
> it will be hard to remove from Koha, but any third-party integrations
> would need to refactor to use a different option.
This might not be a huge factor, though of course removing that header
should go through a deprecation procedure.
Specifically, upon skimming the results of a GitHub search of
"x-koha-query", the only uses I found outside of Koha itself were in
plugins published by a couple active community members.
Regards,
Galen
--
Galen Charlton
Implementation and IT Manager
Equinox Open Library Initiative
gmc@equinoxOLI.org <mailto:gmc@equinoxOLI.org>
https://www.equinoxOLI.org
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org <mailto: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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20221206/59d9e5f6/attachment-0001.htm>
------------------------------
Message: 3
Date: Tue, 6 Dec 2022 12:27:58 +1100
From: "David Cook" <dcook@prosentient.com.au>
To: "'koha-devel'" <koha-devel@lists.koha-community.org>
Subject: [Koha-devel] Maximum execution time for background jobs?
Message-ID: <083d01d90911$faa6cdf0$eff469d0$@prosentient.com.au>
Content-Type: text/plain; charset="utf-8"
Hi all,
I was closing old Bugzilla bugs when I bumped into "Bug 10460 - way to stop
a run away report".
It got me thinking about maximum execution time for background jobs. What do
people think about background jobs workers killing their child processes if
they exceed a maximum execution time?
I don't have a particular use case for it at the moment, so not a priority
by any means, but thoughts on the concept?
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/20221206/34ab783f/attachment.htm>
------------------------------
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 205, Issue 11
*******************************************
NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.