<!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 6960 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is : <br><br>Title : Koha-devel Digest, Vol 205, Issue 10<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: Good enough? (Tomas Cohen Arazi)<br> 2. Fundamental flaw in Koha REST API (David Cook)<br> 3. Re: Fundamental flaw in Koha REST API (Galen Charlton)<br> 4. Re: Fundamental flaw in Koha REST API (Tomas Cohen Arazi)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Mon, 5 Dec 2022 17:15:22 -0300<br>From: Tomas Cohen Arazi <tomascohen@gmail.com><br>To: Julian Maurice <julian.maurice@biblibre.com><br>Cc: koha-devel@lists.koha-community.org<br>Subject: Re: [Koha-devel] Good enough?<br>Message-ID:<br> <CABZfb=XJPUrPc_tEW_j2UBqcD0nBN9XPhm_7zQT5tpCExvnpFQ@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>El lun, 5 dic 2022 a las 14:24, Julian Maurice (<julian.maurice@biblibre.com>)<br>escribió:<br><br>> Yes it is expensive. But manual testing is much more expensive. I'd<br>> rather pay for some CPU time than do manually what a bot can do better<br>> and faster than me. Free services exist too (CircleCI, github actions, ...)<br>><br><br>When you develop, you usually add some tests and run them, along with<br>related ones that could be broken because of the changes. Running the full<br>test suite is not mandatory.<br>Pushing to a branch somewhere there's CI setup to run the full test suite<br>sounds like a good idea.<br><br><br>><br>> Pushing to a temporary master branch is not a bad idea (a never-broken<br>> master branch sounds nice), but I think it would happen too late.<br>> Patches would have already been rebased multiple times, tested and<br>> reviewed before we notice a test failure.<br>><br><br>Agreed!<br><br><br>> koha-testing-docker feels more like a symptom of the difficulty to run<br>> tests than a satisfying solution. It is probably necessary in order to<br>> run complicated end-to-end tests, but it should not be mandatory to run<br>> simple unit tests.<br>> And ktd is not that easy to use. It can break, and it's not easy to<br>> debug for someone not familiar with docker.<br>><br><br>I don't think it is mandatory, but it is the most convenient way to run in<br>a controlled environment that matches as much as possible the conditions in<br>production. That said, I'm pretty sure we could rely on carton or<br>local::lib to generate an environment to work locally.<br><br><br>> Don't you think it would be a lot easier if we could run `prove t` (or<br>> `npm test` or whatever) on any dev setup and have the same<br>> failures/successes as Jenkins (minus the complicated tests like those<br>> that require selenium) ?<br>> Of course making that happen is not an easy task, but it should be a<br>> long term goal IMO.<br>><br>> Also I think no one wants to be the person that refuse a patch because a<br>> comment is misaligned, so if that kind of thing is not automated, "not<br>> good enough code" will continue to be pushed.<br>><br>><br>> Le 05/12/2022 à 14:55, Jonathan Druart a écrit :<br>> > I don't think we should run the whole test suite everytime we attach<br>> > patches, that would be very expensive in terms of resources.<br>> > However it would be interesting to have a temporary 'master' branch<br>> > that would become 'master' only if jenkins is happy.<br>> > "master" would never be broken :D<br>><br><br>That would only save us some reverts if the authors fail to provide fixes.<br>But I don't think reverts happen so often we need to change our workflow<br>to avoid them. And jenkins to fail is the goal of it. We don't need it<br>green all day, we need it to catch the errors (lots of errors are not<br>covered by tests, and that's something we need to invest time on) and devs<br>to take responsibility of fixing their breakages. I will take the blame<br>there, because Jenkins notifications are not reaching the devs inboxes, and<br>we need it fixed ASAP.<br><br>-- <br>Tomás Cohen Arazi<br>Theke Solutions (http://theke.io)<br>✆ +54 9351 3513384<br>GPG: B2F3C15F<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20221205/457361ea/attachment-0001.htm><br><br>------------------------------<br><br>Message: 2<br>Date: Tue, 6 Dec 2022 09:40:00 +1100<br>From: "David Cook" <dcook@prosentient.com.au><br>To: "'koha-devel'" <koha-devel@lists.koha-community.org><br>Subject: [Koha-devel] Fundamental flaw in Koha REST API<br>Message-ID: <07f401d908fa$85ab1bd0$91015370$@prosentient.com.au><br>Content-Type: text/plain; charset="cp1256"<br><br>Hi all,<br><br> <br><br>Just wondering if my email titled “x-koha-query header doesn't support UTF-8<br>data” actually made it to the koha-devel list as I didn’t get any replies to<br>what I perceive as a significant issue.<br><br> <br><br>Basically, the x-koha-query header can only support ISO 8859-1/Latin-1<br>encoded characters. If you try to send UTF-8 encoded data to the API via<br>Javascript, it will silently fail. See Bug 32401 for a practical example of<br>this.<br><br> <br><br>I encountered this issue when using Arabic, but it is also obvious when<br>using Hebrew, Chinese, Devanagari, or any non-Latin based script. <br><br> <br><br>It is less obvious – but still a problem – for some languages like Dutch,<br>Finnish, French, and German. For instance, a x-koha-query header containing<br>the French word “cœur” will fail, because œ is not a ISO 8859-1/Latin-1<br>character. (See the Wikipedia entry for ISO 8859-1 for more examples of<br>problems with languages mostly covered by Latin-1.)<br><br> <br><br>Koha devs need to discuss this and possibly remove “x-koha-query” from Koha.<br><br><br> <br><br>At the moment, it’s not widely used by Koha itself, so I don’t think it will<br>be hard to remove from Koha, but any third-party integrations would need to<br>refactor to use a different option. <br><br> <br><br>Anyway, it would be great if someone could acknowledge receipt of this<br>email. <br><br> <br><br>I have figured out how to get DataTables to stop using x-koha-query, so I’m<br>going to do that for the particular acquisitions problem mentioned in Bug<br>32401, but we do need to talk about this issue. <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/20221206/e423422a/attachment-0001.htm><br><br>------------------------------<br><br>Message: 3<br>Date: Mon, 5 Dec 2022 18:08:00 -0500<br>From: Galen Charlton <gmc@equinoxoli.org><br>To: David Cook <dcook@prosentient.com.au><br>Cc: koha-devel <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] Fundamental flaw in Koha REST API<br>Message-ID:<br> <CAPLnt66y0Mb-bkCVBRsBc0nMqTPOjau6zXyb1kFc9PmtBYJ6rg@mail.gmail.com><br>Content-Type: text/plain; charset="UTF-8"<br><br>Hi,<br><br>On Mon, Dec 5, 2022 at 5:40 PM David Cook <dcook@prosentient.com.au> wrote:<br>> At the moment, it’s not widely used by Koha itself, so I don’t think<br>> it will be hard to remove from Koha, but any third-party integrations<br>> would need to refactor to use a different option.<br><br>This might not be a huge factor, though of course removing that header<br>should go through a deprecation procedure.<br><br>Specifically, upon skimming the results of a GitHub search of<br>"x-koha-query", the only uses I found outside of Koha itself were in<br>plugins published by a couple active community members.<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><br><br>------------------------------<br><br>Message: 4<br>Date: Mon, 5 Dec 2022 21:24:27 -0300<br>From: Tomas Cohen Arazi <tomascohen@gmail.com><br>To: Galen Charlton <gmc@equinoxoli.org><br>Cc: David Cook <dcook@prosentient.com.au>, koha-devel<br> <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] Fundamental flaw in Koha REST API<br>Message-ID:<br> <CABZfb=W+GbMwbS+Psi2ynsksR_6n0SM2SqmhYw50cj1z0ZLOZA@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>I recall we used the header at some point, to keep the base query clean<br>when adding new filters.<br><br>The only alternative is forcing the use of some form of ascii encoding<br>(base64?) But I agree we should better deprecate it.<br><br>It's use in the codebase on DT is tied to an option switch and probably not<br>used<br><br><br><br>El lun, 5 dic 2022 20:08, Galen Charlton <gmc@equinoxoli.org> escribió:<br><br>> Hi,<br>><br>> On Mon, Dec 5, 2022 at 5:40 PM David Cook <dcook@prosentient.com.au><br>> wrote:<br>> > At the moment, it’s not widely used by Koha itself, so I don’t think<br>> > it will be hard to remove from Koha, but any third-party integrations<br>> > would need to refactor to use a different option.<br>><br>> This might not be a huge factor, though of course removing that header<br>> should go through a deprecation procedure.<br>><br>> Specifically, upon skimming the results of a GitHub search of<br>> "x-koha-query", the only uses I found outside of Koha itself were in<br>> plugins published by a couple active community members.<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>> _______________________________________________<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>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20221205/d6b096b3/attachment.htm><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 205, Issue 10<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>