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: Good enough? (Tomas Cohen Arazi)
2. Fundamental flaw in Koha REST API (David Cook)
3. Re: Fundamental flaw in Koha REST API (Galen Charlton)
4. Re: Fundamental flaw in Koha REST API (Tomas Cohen Arazi)


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

Message: 1
Date: Mon, 5 Dec 2022 17:15:22 -0300
From: Tomas Cohen Arazi <tomascohen@gmail.com>
To: Julian Maurice <julian.maurice@biblibre.com>
Cc: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] Good enough?
Message-ID:
    <CABZfb=XJPUrPc_tEW_j2UBqcD0nBN9XPhm_7zQT5tpCExvnpFQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

El lun, 5 dic 2022 a las 14:24, Julian Maurice (<julian.maurice@biblibre.com>)
escribió:

> Yes it is expensive. But manual testing is much more expensive. I'd
> rather pay for some CPU time than do manually what a bot can do better
> and faster than me. Free services exist too (CircleCI, github actions, ...)
>

When you develop, you usually add some tests and run them, along with
related ones that could be broken because of the changes. Running the full
test suite is not mandatory.
Pushing to a branch somewhere there's CI setup to run the full test suite
sounds like a good idea.


>
> Pushing to a temporary master branch is not a bad idea (a never-broken
> master branch sounds nice), but I think it would happen too late.
> Patches would have already been rebased multiple times, tested and
> reviewed before we notice a test failure.
>

Agreed!


> koha-testing-docker feels more like a symptom of the difficulty to run
> tests than a satisfying solution. It is probably necessary in order to
> run complicated end-to-end tests, but it should not be mandatory to run
> simple unit tests.
> And ktd is not that easy to use. It can break, and it's not easy to
> debug for someone not familiar with docker.
>

I don't think it is mandatory, but it is the most convenient way to run in
a controlled environment that matches as much as possible the conditions in
production. That said, I'm pretty sure we could rely on carton or
local::lib to generate an environment to work locally.


> Don't you think it would be a lot easier if we could run `prove t` (or
> `npm test` or whatever) on any dev setup and have the same
> failures/successes as Jenkins (minus the complicated tests like those
> that require selenium) ?
> Of course making that happen is not an easy task, but it should be a
> long term goal IMO.
>
> Also I think no one wants to be the person that refuse a patch because a
> comment is misaligned, so if that kind of thing is not automated, "not
> good enough code" will continue to be pushed.
>
>
> Le 05/12/2022 à 14:55, Jonathan Druart a écrit :
> > I don't think we should run the whole test suite everytime we attach
> > patches, that would be very expensive in terms of resources.
> > However it would be interesting to have a temporary 'master' branch
> > that would become 'master' only if jenkins is happy.
> > "master" would never be broken :D
>

That would only save us some reverts if the authors fail to provide fixes.
But I don't think reverts happen so often we need to change our workflow
to avoid them. And jenkins to fail is the goal of it. We don't need it
green all day, we need it to catch the errors (lots of errors are not
covered by tests, and that's something we need to invest time on) and devs
to take responsibility of fixing their breakages. I will take the blame
there, because Jenkins notifications are not reaching the devs inboxes, and
we need it fixed ASAP.

--
Tomás Cohen Arazi
Theke Solutions (http://theke.io)
✆ +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20221205/457361ea/attachment-0001.htm>

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

Message: 2
Date: Tue, 6 Dec 2022 09:40:00 +1100
From: "David Cook" <dcook@prosentient.com.au>
To: "'koha-devel'" <koha-devel@lists.koha-community.org>
Subject: [Koha-devel] Fundamental flaw in Koha REST API
Message-ID: <07f401d908fa$85ab1bd0$91015370$@prosentient.com.au>
Content-Type: text/plain; charset="cp1256"

Hi all,



Just wondering if my email titled “x-koha-query header doesn't support UTF-8
data” actually made it to the koha-devel list as I didn’t get any replies to
what I perceive as a significant issue.



Basically, the x-koha-query header can only support ISO 8859-1/Latin-1
encoded characters. If you try to send UTF-8 encoded data to the API via
Javascript, it will silently fail. See Bug 32401 for a practical example of
this.



I encountered this issue when using Arabic, but it is also obvious when
using Hebrew, Chinese, Devanagari, or any non-Latin based script.



It is less obvious – but still a problem – for some languages like Dutch,
Finnish, French, and German. For instance, a x-koha-query header containing
the French word “cœur” will fail, because œ is not a ISO 8859-1/Latin-1
character. (See the Wikipedia entry for ISO 8859-1 for more examples of
problems with languages mostly covered by Latin-1.)



Koha devs need to discuss this and possibly remove “x-koha-query” from Koha.




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.



Anyway, it would be great if someone could acknowledge receipt of this
email.



I have figured out how to get DataTables to stop using x-koha-query, so I’m
going to do that for the particular acquisitions problem mentioned in Bug
32401, but we do need to talk about this issue.



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/e423422a/attachment-0001.htm>

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

Message: 3
Date: Mon, 5 Dec 2022 18:08:00 -0500
From: Galen Charlton <gmc@equinoxoli.org>
To: David Cook <dcook@prosentient.com.au>
Cc: koha-devel <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] Fundamental flaw in Koha REST API
Message-ID:
    <CAPLnt66y0Mb-bkCVBRsBc0nMqTPOjau6zXyb1kFc9PmtBYJ6rg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

Hi,

On Mon, Dec 5, 2022 at 5:40 PM David Cook <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
https://www.equinoxOLI.org
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581


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

Message: 4
Date: Mon, 5 Dec 2022 21:24:27 -0300
From: Tomas Cohen Arazi <tomascohen@gmail.com>
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
Message-ID:
    <CABZfb=W+GbMwbS+Psi2ynsksR_6n0SM2SqmhYw50cj1z0ZLOZA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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> escribió:

> Hi,
>
> On Mon, Dec 5, 2022 at 5:40 PM David Cook <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
> https://www.equinoxOLI.org
> phone: 877-OPEN-ILS (673-6457)
> direct: 770-709-5581
> _______________________________________________
> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20221205/d6b096b3/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 10
*******************************************