Re: [Koha-devel] Koha CSRF protection

[Julian Maurice via Koha-devel]

Ohhh I forgot that .pl scripts almost never check for the HTTP method... 
That's the thing I was missing. Thanks!


Le 2024-04-13 10:24, Tomas Cohen Arazi a écrit :
The thing is we don't have a spec for each endpoint as we do for the 
API.

So people could be tricked to send a GET with a similar form, to an
endpoint (the .pl script) and bypass the generic CSRF check we do.

Also, this ways programmers and the QA team have a simpler way to 
detect
state-changing workflows that are unprotected: changes something? It 
needs

to be a POST with cus-, otherwise Koha will let you know you missed
something.

Hope it clarifies.

El sáb, 13 abr 2024 10:18, Julian Maurice via Koha-devel <
koha-devel@lists.koha-community.org> escribió:


My point is: since all POST (and other unsafe methods) requests are
protected and require a CSRF token, why does Koha have a requirement 
on
the 'op' parameter for those requests ? It seems redundant and can 
cause

unnecessary failure (I can't POST with 'op=search' even with a valid
CSRF token, I don't understand why)

And for safe methods (GET, HEAD, OPTIONS, TRACE), if someone 
identifies
that it's doing a CUD operation, why modify the 'op' parameter since 
you

need to also change the method to POST anyway ?
This can be reworded as: How can we end up in a situation where 'op' 
has

been fixed ("cud-" prefix added) but not the HTTP method ?

Le 2024-04-12 20:41, Jonathan Druart a écrit :
> We want to know which requests to protect (ie. Requiring a csrf token):
> those having a op starting with cud-
> Otherwise you could GET something that should be POSTed.
> I've tried to describe this change as best as I could on the wiki,
> please
> adjust if it's not clear enough.
> https://wiki.koha-community.org/wiki/Coding_Guidelines#CSRF_protection
>
> On Fri, 12 Apr 2024, 15:00 Julian Maurice via Koha-devel, <
> koha-devel@lists.koha-community.org> wrote:
>
>> Hi,
>>
>> I'm a bit late on the topic but I had a look at the different bugs and
>> patches during hackfest (mainly because it didn't work for me, I will
>> open a new bug report for that).
>>
>> There is something in it that seems to cause bugs and I don't see a
>> reason for it: it's the "cud-" thing.
>>
>> As I understand it, now every request that create/update/delete
>> something should be POST (or PUT/DELETE/PATCH) requests and have an
>> 'op'
>> parameter whose value start with 'cud-' and all other requests should
>> be
>> GET (or OPTIONS/TRACE/HEAD) requests and if they have an 'op'
>> parameter
>> it should not start with "cud-".
>> Why do we need the "cud-" prefix if we can use the HTTP method for
>> detecting which requests need to be protected ?
>>
>> What seems strange is that the current implementation will allow a
>> POST
>> request without an 'op' parameter, but will block a POST request with
>> an
>> 'op' parameter that does not start with 'cud-'.
>> It looks like we could get rid of this prefix check without losing
>> anything. What did I miss ?
>>
>> Le 04/03/2024 à 08:37, Marcel de Rooy via Koha-devel a écrit :
>> > Great work!
>> >
>> > *From:*Koha-devel  *On
>> > Behalf Of *Nick Clemens via Koha-devel
>> > *Sent:* Friday, March 1, 2024 2:26 PM
>> > *To:* Koha Devel ; Koha
>> > 
>> > *Subject:* [Koha-devel] Koha CSRF protection
>> >
>> > Hello all!
>> >
>> > We have pushed the CSRF work from 34478 and related bugs today. We
know
>> > there are more follow-ups needed, and have filed a series of bugs
under
>> > an omnibus:
>> >
>> > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192
>> > <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192>
>> >
>> > We have a framapad where issues can be reported/found:
>> >
>> > https://annuel.framapad.org/p/koha_34478_remaining
>> > <https://annuel.framapad.org/p/koha_34478_remaining>
>> >
>> > And we have bugs for each of the sections of the document. We need all
>> > developers to submit patches when they encounter issues, and for other
>> > users testing master to report found issues on the pad. Testers can
>> > report issues on the pad as well.
>> >
>> > There is a new coding guideline - all POSTs to forms in Koha will need
>> > to include a csrf token:
>> >
>> > https://wiki.koha-community.org/wiki/Coding_Guidelines#Security
>> > <https://wiki.koha-community.org/wiki/Coding_Guidelines#Security>
>> >
>> > This has been a big work, many thanks to all involved, and 

Re: [Koha-devel] Koha CSRF protection

[Julian Maurice via Koha-devel]

My point is: since all POST (and other unsafe methods) requests are 
protected and require a CSRF token, why does Koha have a requirement on 
the 'op' parameter for those requests ? It seems redundant and can cause 
unnecessary failure (I can't POST with 'op=search' even with a valid 
CSRF token, I don't understand why)


And for safe methods (GET, HEAD, OPTIONS, TRACE), if someone identifies 
that it's doing a CUD operation, why modify the 'op' parameter since you 
need to also change the method to POST anyway ?
This can be reworded as: How can we end up in a situation where 'op' has 
been fixed ("cud-" prefix added) but not the HTTP method ?


Le 2024-04-12 20:41, Jonathan Druart a écrit :

We want to know which requests to protect (ie. Requiring a csrf token):
those having a op starting with cud-
Otherwise you could GET something that should be POSTed.
I've tried to describe this change as best as I could on the wiki, 
please

adjust if it's not clear enough.
https://wiki.koha-community.org/wiki/Coding_Guidelines#CSRF_protection

On Fri, 12 Apr 2024, 15:00 Julian Maurice via Koha-devel, <
koha-devel@lists.koha-community.org> wrote:


Hi,

I'm a bit late on the topic but I had a look at the different bugs and
patches during hackfest (mainly because it didn't work for me, I will
open a new bug report for that).

There is something in it that seems to cause bugs and I don't see a
reason for it: it's the "cud-" thing.

As I understand it, now every request that create/update/delete
something should be POST (or PUT/DELETE/PATCH) requests and have an 
'op'
parameter whose value start with 'cud-' and all other requests should 
be
GET (or OPTIONS/TRACE/HEAD) requests and if they have an 'op' 
parameter

it should not start with "cud-".
Why do we need the "cud-" prefix if we can use the HTTP method for
detecting which requests need to be protected ?

What seems strange is that the current implementation will allow a 
POST
request without an 'op' parameter, but will block a POST request with 
an

'op' parameter that does not start with 'cud-'.
It looks like we could get rid of this prefix check without losing
anything. What did I miss ?

Le 04/03/2024 à 08:37, Marcel de Rooy via Koha-devel a écrit :
> Great work!
>
> *From:*Koha-devel  *On
> Behalf Of *Nick Clemens via Koha-devel
> *Sent:* Friday, March 1, 2024 2:26 PM
> *To:* Koha Devel ; Koha
> 
> *Subject:* [Koha-devel] Koha CSRF protection
>
> Hello all!
>
> We have pushed the CSRF work from 34478 and related bugs today. We know
> there are more follow-ups needed, and have filed a series of bugs under
> an omnibus:
>
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192
> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192>
>
> We have a framapad where issues can be reported/found:
>
> https://annuel.framapad.org/p/koha_34478_remaining
> <https://annuel.framapad.org/p/koha_34478_remaining>
>
> And we have bugs for each of the sections of the document. We need all
> developers to submit patches when they encounter issues, and for other
> users testing master to report found issues on the pad. Testers can
> report issues on the pad as well.
>
> There is a new coding guideline - all POSTs to forms in Koha will need
> to include a csrf token:
>
> https://wiki.koha-community.org/wiki/Coding_Guidelines#Security
> <https://wiki.koha-community.org/wiki/Coding_Guidelines#Security>
>
> This has been a big work, many thanks to all involved, and there is
> still work to be done, but this is an important fix that we must do.
>
> You can reach out to me on IRC (kidclamp) or via email and I will do my
> best to help anyone contribute.
>
> Thanks,
>
> Nick
>
>
> --
>
> Nick Clemens
>
> ByWater Solutions
>
> bywatersolutions.com <http://bywatersolutions.com/>
>
> Phone: (888) 900-8944
>
> Pronouns: (he/him/his)
> Timezone: Eastern
>
> Follow us:
>
> <https://www.facebook.com/ByWaterSolutions/>
> <https://www.instagram.com/bywatersolutions/>
> <https://www.youtube.com/user/bywatersolutions>
> <https://twitter.com/ByWaterSolution>
>
>
> ___
> 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/
___
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/


___
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/

Re: [Koha-devel] Koha CSRF protection

[Julian Maurice via Koha-devel]

Hi,

I'm a bit late on the topic but I had a look at the different bugs and 
patches during hackfest (mainly because it didn't work for me, I will 
open a new bug report for that).


There is something in it that seems to cause bugs and I don't see a 
reason for it: it's the "cud-" thing.


As I understand it, now every request that create/update/delete 
something should be POST (or PUT/DELETE/PATCH) requests and have an 'op' 
parameter whose value start with 'cud-' and all other requests should be 
GET (or OPTIONS/TRACE/HEAD) requests and if they have an 'op' parameter 
it should not start with "cud-".
Why do we need the "cud-" prefix if we can use the HTTP method for 
detecting which requests need to be protected ?


What seems strange is that the current implementation will allow a POST 
request without an 'op' parameter, but will block a POST request with an 
'op' parameter that does not start with 'cud-'.
It looks like we could get rid of this prefix check without losing 
anything. What did I miss ?


Le 04/03/2024 à 08:37, Marcel de Rooy via Koha-devel a écrit :

Great work!

*From:*Koha-devel  *On 
Behalf Of *Nick Clemens via Koha-devel

*Sent:* Friday, March 1, 2024 2:26 PM
*To:* Koha Devel ; Koha 


*Subject:* [Koha-devel] Koha CSRF protection

Hello all!

We have pushed the CSRF work from 34478 and related bugs today. We know 
there are more follow-ups needed, and have filed a series of bugs under 
an omnibus:


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 



We have a framapad where issues can be reported/found:

https://annuel.framapad.org/p/koha_34478_remaining 



And we have bugs for each of the sections of the document. We need all 
developers to submit patches when they encounter issues, and for other 
users testing master to report found issues on the pad. Testers can 
report issues on the pad as well.


There is a new coding guideline - all POSTs to forms in Koha will need 
to include a csrf token:


https://wiki.koha-community.org/wiki/Coding_Guidelines#Security 



This has been a big work, many thanks to all involved, and there is 
still work to be done, but this is an important fix that we must do.


You can reach out to me on IRC (kidclamp) or via email and I will do my 
best to help anyone contribute.


Thanks,

Nick


--

Nick Clemens

ByWater Solutions

bywatersolutions.com 

Phone: (888) 900-8944

Pronouns: (he/him/his)
Timezone: Eastern

Follow us:

 
 
 




___
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/

___
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/

[Koha-devel] Random data in CGI Vars

[Julian Maurice]

Hello,

I've been encountering strange bugs on two different Koha instances 
(both 21.11). When cataloguing new records, instead of the record being 
saved, users are being redirected to an empty cataloguing form (like if 
they clicked on "New record"). They have to use "Back" and submit the 
form again until it works.


I suspected something going wrong in how the form data was being sent to 
Koha so I added the following line in cataloguing/addbiblio.pl


warn Data::Dumper->Dump([{ $input->Vars }], ['Vars']) . "\n";

right after CGI->new
And indeed there is something going wrong. Some of the variables are 
replaced by random data. Here's an example:


  'tag_041_subfield_a_452653_624274' => '',
  '' => "Ly[\x{1cf}^KJ{)Z\x{fffd}(-D<\x{fffd}\x{fffd}\x{fffd}BN",
  'tag_856_code_x_883542_376496' => 'x',

Sometimes the 'op' parameter is replaced by random data, and that's why 
we see this strange behaviour.


Have you ever experienced something like this ? Do you know where it 
could come from ?


--
Julian Maurice
BibLibre
___
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/

Re: [Koha-devel] Good enough?

[Julian Maurice]

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, ...)


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.


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.


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

Using koha-testing-docker it's very easy to run tests locally.
It will be even more easier with
https://gitlab.com/koha-community/koha-misc4dev/-/issues/58

Le ven. 2 déc. 2022 à 18:16, Julian Maurice
 a écrit :


Hi,

It seems to me that several issues could be solved by having the CI run
sooner, so authors can have feedback as soon as possible. Something like
github's CI integration with pull requests would be amazing to detect
common mistakes early and stop wasting human time. We should know if
tests pass before pushing to master, not after.
We could check tidyness, commit message conventions, code coverage by
tests, ... all before another person have to look at it.

Also tests are not easy to run locally. They might pass on Jenkins, but
they do not on my local setup, so they are basically useless to tell me
if I broke something. It also makes writing new tests more difficult
than it should.

If I wanted to improve Koha developer experience, I would start with that.

My 2 cents.

Le 02/12/2022 à 15:42, Jonathan Druart a écrit :

Hi devs,

I was wondering... How good is your "good enough"?
It's a question I often ask myself, when writing patches or QAing
yours: is it good enough to be into Koha? It does not have to be
perfect or it may never reach master, but it must meet certain
standards.

When I was RM I tried to put that limit quite high. Not necessarily by
asking the author for improving the follow-up patches, but also by
adding the missing bits myself.

There are various types of "good enough", depending on what we look
at: good enough to be reviewed, good enough to be tested, to be put in
production, get feedback, try an idea, etc.

Most of the time, what is driving the limit is answering  the
questions "Is it maintainable?" / "Is it future proof?". Making sure
the code you are writing won't be broken inadvertently is very
important and must be part of the reflection.

Katrin asked the QA team members what were our plans for 23.05. In my
opinion we should enforce this "be future proof" concept. Writing code
is easy, especially in Koha (yes it is!). Writing maintainable and
robust code, following our guidelines is a bit harder. That's why we
have a QA process that tries to catch inconsistencies or edge cases
you may have missed.
But I think we can be even more rigorous, and aim for better
standards. We can elevate our ambitions and do better. When we see the
number of new enhancements we are releasing every 6 months, it shows
well that writing code is definitely not a problem. However sometimes
developers are tempted to abandon their work once they are pushed to
master. Pushed does not mean "done". Providing bug fixes, following-up
with patches when needed, fixing CI jenkins, etc. is part of job
(/fun)

As a Koha developer for a long time now, I know how frustrating it can
be to be asked for follow-ups/rewrite/tests to have our patches
stamped with the precious PQA mark. But from the other point of view
(RM, RMaints, QA team), I also know it's very frustrating when you are
in charge of the release and you do not get the appropriate follow-up
work once it's pushed to master.

There are some easy steps to write/review better patches. All have
been discussed already several times, b

Re: [Koha-devel] Good enough?

[Julian Maurice]

ld be
caused by your patches.

6. Be strict if you are QAing. Each QA member has their own "good
enough", and the RM as well (either relying on the QAer or providing a
full review). But QA must fail if the code is old Koha style code, or
not "good enough".

7. Provide support for failing tests, fix things you broke. The QA
team will be more comfortable with your patches if you show them you
are providing support for your stuff.
It's not because it's pushed that you don't have any more efforts to
make. Provide follow-up patches you promised, provide bug fixes, etc.
We don't have a good way to keep track of such demands, which does not
make tracking easier for devs, QA and RM. Any suggestions?

8. QA team MUST NEVER* pass QA a change that is not covered by tests,
never. You should not provide change to modules without tests!
* almost never...

9. Stick to existing patterns. We should not have different ways to do
the same thing. We should not have different places where a code is
doing the same thing. Ask for help or advice on the list or IRC before
you start coding. We will be happy to guide you. Even if you are a
regular Koha developer it's not always easy to be aware of the latest
master changes.
We will tell you what's the current good practice, or point you to
examples you could reuse for what you want to implement.

10. CI should drive the pushes. No more push if CI is not green. The
more we wait the harder it is to track down the origin of the problem.
Last cycle some jobs have been red for months, and we released
22.11.00 with D10, D11, D12 marked unstable...

What will I do next cycle?
All of that, and more. I will track down jenkins failures and
responsibilize developers telling them when they break tests (and
won't fix them anymore as I have been doing for years).
I will raise on the bug reports what could have been improved. Yes,
read that I will be even more annoying (to put it politely) than
before.

I've noticed that the pre-commit git hook on the wiki has been broken
for more than 3 years. And also caught some core developers that do
not have it in place. I am relying on it to keep Vue files tidy so
it's important to have it set up properly. I am planning to force its
usage for ktd users [2]. Adding more checks to it will help us to
catch inconsistencies from the beginning.

To summarize, writing code is cheap, maintaining code is way more
expensive! It is easier to get the attention of developers before the
patches are pushed to master than after, so we could be more ambitious
and ask more.

For discussion :)

Cheers,
Jonathan

[1] If you are using vim, open ~/vimrc, add
   vmap  :!perltidy -q
Reload vim, select code in visual mode
[2] https://gitlab.com/koha-community/koha-misc4dev/-/issues/59
___
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/


--
Julian Maurice
BibLibre
___
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/

[Koha-devel] Staff interface redesign is ready to be tested

[Julian Maurice]

Hi all,

After 5 months of work, the new staff interface is finally there!

As it changes a lot of pages, we will need a lot of eyes to hunt down 
bugs. So if you want to help, you can go to bug 30952 right now and 
start testing!


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30952

--
Julian Maurice
BibLibre
___
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/

Re: [Koha-devel] Replace git-filter-branch with git-filter-repo

[Julian Maurice]

Hi,

Just to add another way of doing it without installing a new tool:

I use `git rebase -x "git signoff" HEAD~`
signoff is an alias to 'commit --amend -s --no-edit'

I didn't time it, but it always takes less than a second

So, to have the same 'so' alias:

so = "!f() { git rebase -x 'git commit --amend -s --no-edit' HEAD~$1; };f"

One of the benefit of this method is that you can re-run the same 
command twice, it will add the signoff line only once.


Le 16/06/2022 à 09:26, Jonathan Druart a écrit :

Hi devs,

[I sent this on Aug 26th 2021 but it never reached the list!]

You may have seen the following warning when signing off on patches
using the git alias

"""
WARNING: git-filter-branch has a glut of gotchas generating mangled
history
  rewrites.  Hit Ctrl-C before proceeding to abort, then use an
  alternative filtering tool such as 'git filter-repo'
  (https://github.com/newren/git-filter-repo/) instead.  See
the
  filter-branch manual page for more details; to squelch this
warning,
  set FILTER_BRANCH_SQUELCH_WARNING=1.
Proceeding with filter-branch...
"""

And yes, it's very slow, `time git so 1` takes around 10 sec for me.

You can switch to git-filter-repo (https://github.com/newren/git-filter-repo).

First, install it (`pip3 install git-filter-repo` should do it,
otherwise read their install doc
https://github.com/newren/git-filter-repo/blob/main/INSTALL.md).

Then adjust the git alias (~/.gitconfig):

   so = "!f() { c=`expr $1 - 1`; git filter-repo --message-callback
'return message + b\"\\nSigned-off-by: Full Name \"' --refs
HEAD~$c^..; }; f"

I am using 'so' but you may use something else as it's not what is on the wiki.
"Completely finished after 0.20 seconds."

Cheers,
Jonathan
___
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/


--
Julian Maurice
BibLibre
___
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/

Re: [Koha-devel] Follow-up patches and why not to use them

[Julian Maurice]

Hi Joonas,

Do you know you can revert multiple commits at once (ie. only one 
"revert commit" that revert a series of commits) ? Would that make it 
easier for cases like that ?
And when trying to find all commits of a particular bug, git log --grep 
is your friend.


Also, you can show a list of commits as a single diff. I have a git 
alias defined to "diff origin/HEAD..." which shows all differences on my 
local branch from the remote default branch (master).


When you have a lot of patches, I agree that it is sometimes useful to 
see it as a single patch (that's why I have this git alias). But often 
it makes sense to have separate patches.


By enforcing a "1 commit" rule we would lose the (often) logical 
separation of patches that makes review easier.


That being said, there are other times where it would have made sense to 
just squash all commits together before pushing them to master. So I 
guess my opinion can be summarized at "it depends" :-)


Le 04/06/2021 à 12:36, Joonas Kylmälä a écrit :

Hi,

I just bumped in another case of follow-up patch style causing us
trouble. In bug
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28490 I had to
spend considerable amount of time just reverting all the problematic
patches and making sure I didn't miss any related patches, instead of
just reverting one patch and knowing I would be good to go with that.
Reverting this many patches also means a lot more review work yet again
because you have no commit messages to reference to easily or if you
want to use those you have to jump from patch to patch to find out what
the change does. And this extra review work needs to be done by two
people when reverting such follow-up patch series!

If we instead asked the original author to fix the patches then this
work would need to be done only ~once. The argument against this I have
heard is that it makes the review work harder because you don't know
what has changed since the previous version. I think however that is not
very useful because the second reviewer doesn't benefit from this at all
and makes their work harder and also the first reviewer even sometimes
might review the revision after many days by which time they have
forgotten already the context so basically they end up in the same
situation as the second reviewer and have to jump between patches.

Just my two cents, I hope we can stop doing follow-ups and instead have
commits which contain one single change to decrease our time spent on
review and make sure we don't miss any problems due to having to jump
between so many contexts.

Joonas
___
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/



--
Julian Maurice
BibLibre
___
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/

Re: [Koha-devel] Why is config ($KOHA_CONF) stored in memcached ?

[Julian Maurice]

If you're interested there is also bug 28278 that divides by 3 the time 
needed to parse $KOHA_CONF:

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28278

Le 02/05/2021 à 14:52, Julian Maurice a écrit :
Patch is ready to be tested at 
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28276 ;)


Le 01/05/2021 à 14:53, Tomas Cohen Arazi a écrit :

I vote for fixing it so the file is only hit the first time.

El vie, 30 abr 2021 a las 14:19, Julian Maurice 
(mailto:julian.maur...@biblibre.com>>) 
escribió:


    Hi all,

    Maybe it's a dumb question, but I don't understand why the config is
    stored in memcached as:
    - memcached server address is in this config, so we need to read
    $KOHA_CONF file first in order to connect to memcached server
    - config is kept in memory forever ($C4::Context::context), so we
    shouldn't need the cache once starman has started.

    If you add a warning in Koha::Config::read_from_file, you'll see that
    the file is read 3 times per worker, even when the config already 
exist

    in cache (it's read 4 times when the cache is empty).
    It's read each time we call Koha::Cache->new (+ in 
C4::Context->new if

    the cache is empty)

    Shouldn't we read the file only in C4::Context->new (without using
    cache), and make Koha::Cache use C4::Context->config instead ?

    --     Julian Maurice
    BibLibre
    ___
    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

<https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel>

    website : https://www.koha-community.org/
    <https://www.koha-community.org/>
    git : https://git.koha-community.org/ 
<https://git.koha-community.org/>

    bugs : https://bugs.koha-community.org/
    <https://bugs.koha-community.org/>



--
Tomás Cohen Arazi
Theke Solutions (http://theke.io <http://theke.io/>)
✆ +54 9351 3513384
GPG: B2F3C15F




--
Julian Maurice
BibLibre
___
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/

Re: [Koha-devel] Why is config ($KOHA_CONF) stored in memcached ?

[Julian Maurice]

Patch is ready to be tested at 
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28276 ;)


Le 01/05/2021 à 14:53, Tomas Cohen Arazi a écrit :

I vote for fixing it so the file is only hit the first time.

El vie, 30 abr 2021 a las 14:19, Julian Maurice 
(mailto:julian.maur...@biblibre.com>>) 
escribió:


Hi all,

Maybe it's a dumb question, but I don't understand why the config is
stored in memcached as:
- memcached server address is in this config, so we need to read
$KOHA_CONF file first in order to connect to memcached server
- config is kept in memory forever ($C4::Context::context), so we
shouldn't need the cache once starman has started.

If you add a warning in Koha::Config::read_from_file, you'll see that
the file is read 3 times per worker, even when the config already exist
in cache (it's read 4 times when the cache is empty).
It's read each time we call Koha::Cache->new (+ in C4::Context->new if
the cache is empty)

Shouldn't we read the file only in C4::Context->new (without using
cache), and make Koha::Cache use C4::Context->config instead ?

    -- 
Julian Maurice

BibLibre
___
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
<https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel>
website : https://www.koha-community.org/
<https://www.koha-community.org/>
git : https://git.koha-community.org/ <https://git.koha-community.org/>
bugs : https://bugs.koha-community.org/
<https://bugs.koha-community.org/>



--
Tomás Cohen Arazi
Theke Solutions (http://theke.io <http://theke.io/>)
✆ +54 9351 3513384
GPG: B2F3C15F


--
Julian Maurice
BibLibre
___
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/

Re: [Koha-devel] git trick for compiled CSS

[Julian Maurice]

Hi Frido,

This nice trick made me wonder if git could beautify the css before 
making the diff... and of course it does!


https://scripter.co/git-diff-minified-js-and-css/

It requires installing a node package and modifying some git files, but 
it works really well


Le 29/04/2021 à 17:19, Fridolin SOMERS a écrit :

Hi,

I'd like to share a trick.

When generating compiled CSS files, no way to check the git diff since 
all is on one line.


I've managed to find a trick :

git show --word-diff shows chucks deleted/added so with some regexp :

git show --word-diff $SHA1 | egrep '(\[\-)|(\{\+)' | sed -r 
's/^.*(\[\-.*\-\]\{\+.*\+\}).*$/\1/g'


For example :

aebd3f6a53 Bug 27566: Compiled CSS

[-textarea{font-family:NotoSans}.navbar-]{+textarea{font-family:NotoSans,sans-serif}.navbar+} 

[-textarea{font-family:NotoSans}.navbar-]{+textarea{font-family:NotoSans,sans-serif}.navbar+} 

[-textarea{font-family:NotoSans}.navbar-]{+textarea{font-family:NotoSans,sans-serif}.navbar+} 

[-textarea{font-family:NotoSans}.navbar-]{+textarea{font-family:NotoSans,sans-serif}.navbar+} 



This is very usefull to check that compilation worked and did not broke 
the 90% of the file XD


Best regards :D



--
Julian Maurice
BibLibre
___
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/

Re: [Koha-devel] Template::Toolkit and Translations

[Julian Maurice]

About the different translation functions, here's a tip: just remember 
"__npx" where each letter is an optional flag

n for Numbers (plural forms)
p for Particular context
x for eXtra variables

And in templates, where functions starting with '_' are considered 
private, the '__' prefix was replaced by 't' (but maybe we should use 
the 't' form everywhere to remove confusion ?)


Also you can refer to 
https://git.koha-community.org/Koha-community/Koha/src/branch/master/docs/development/internationalization.md


About database VS hardcoded list, what about a hardcoded but extensible 
list ?
For instance you'd have the full ISO-639-* lists hardcoded in Perl, but 
it would be extensible, either by adding entries to the database, or by 
plugins.


Le 27/04/2021 à 01:44, dc...@prosentient.com.au a écrit :

Hi Julian,

I like part of what you've suggested here. I still think that putting languages 
(with codes and name in native text) in the database is a good idea, as it 
allows the ability to add languages to Koha without a code change. Unless Koha 
is going to be perfectly comprehensive with languages, I think that libraries 
need to be able to add their own languages to the database.

But I'd be fine with putting the translations of languages into Perl rather 
than Template::Toolkit.

I've found the barrier to entry for Koha translations to be too high, so I 
can't keep track of all the different _(), __(), _t(), etc functions across the 
different file types, but if your suggestion for Koha::Languages works using 
that __() syntax, then I'm fine with it.

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
From: Koha-devel  On Behalf Of 
Julian Maurice
Sent: Monday, 26 April 2021 8:17 PM
To: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] Template::Toolkit and Translations

Hi David,

I think that language descriptions would be best in a Perl module, so that they 
can be used everywhere (perl and templates).

For instance:

package Koha::Languages;
use Koha::I18N;
sub getLanguages {
  return {
  en => __('English'),
  fr => __('French'),
  }
}

And if the original description is needed, we can do the same but without the 
__() translation.

sub getLanguagesDescriptionsInTheirOwnLanguage {
  return {
  en => 'English',
  fr => 'Français',
  }
}

Le 26/04/2021 à 02:44, dc...@prosentient.com.au a écrit :

Hi all,

While I mostly work in English, I occasionally do support libraries in
other languages like French, Arabic, and Chinese. And more recently
I’ve been looking at the Languages dropdown in the OPAC advanced search.

In the templates, I notice that we often translate HTML, but what if
we translated strings for a Template::Toolkit data structure instead?

Consider the following:

[% BLOCK en %]Anglais[% END %]

[% BLOCK fr %]Français[% END %]

[% langs.en = INCLUDE en %]

[% langs.fr = INCLUDE fr %]

I suppose it’s not very beautiful, but the translation process should
be simple and in the end we have a re-usable hash map rather than static HTML.

As I commented on Bug 12017
(https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12017
<https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12017>), we
could have a database table of language codes with native language
names, and then iterate through that and use the hash map of
translations to provide the translations. Since we’re not producing
HTML, we could flexibly reuse this language data in various different
contexts. Whether it’s the Languages dropdown in the OPAC advanced
search, the language selector, or whatever.

We could probably use this concept in other places as well where we
need translations but we don’t want to be bound to HTML.

What do people think? I’m not wedded to the idea, but it’s something
that crossed my mind this morning, when I looked at the large switch
statements at
https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html
g=12017=40285
<https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html=12017=40285>.


(To that end, I would also suggest a theme-independent
Template::Toolkit include directory, but that’s another story…)

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

Office: 02 9212 0899

Online: 02 8005 0595


___
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/



--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
websit

Re: [Koha-devel] Template::Toolkit and Translations

[Julian Maurice]

Hi David,

I think that language descriptions would be best in a Perl module, so 
that they can be used everywhere (perl and templates).


For instance:

package Koha::Languages;
use Koha::I18N;
sub getLanguages {
return {
en => __('English'),
fr => __('French'),
}
}

And if the original description is needed, we can do the same but 
without the __() translation.


sub getLanguagesDescriptionsInTheirOwnLanguage {
return {
en => 'English',
fr => 'Français',
}
}

Le 26/04/2021 à 02:44, dc...@prosentient.com.au a écrit :

Hi all,

While I mostly work in English, I occasionally do support libraries in 
other languages like French, Arabic, and Chinese. And more recently I’ve 
been looking at the Languages dropdown in the OPAC advanced search.


In the templates, I notice that we often translate HTML, but what if we 
translated strings for a Template::Toolkit data structure instead?


Consider the following:

[% BLOCK en %]Anglais[% END %]

[% BLOCK fr %]Français[% END %]

[% langs.en = INCLUDE en %]

[% langs.fr = INCLUDE fr %]

I suppose it’s not very beautiful, but the translation process should be 
simple and in the end we have a re-usable hash map rather than static HTML.


As I commented on Bug 12017 
(https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12017 
<https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12017>), we 
could have a database table of language codes with native language 
names, and then iterate through that and use the hash map of 
translations to provide the translations. Since we’re not producing 
HTML, we could flexibly reuse this language data in various different 
contexts. Whether it’s the Languages dropdown in the OPAC advanced 
search, the language selector, or whatever.


We could probably use this concept in other places as well where we need 
translations but we don’t want to be bound to HTML.


What do people think? I’m not wedded to the idea, but it’s something 
that crossed my mind this morning, when I looked at the large switch 
statements at 
https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html=12017=40285 
<https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html=12017=40285>. 



(To that end, I would also suggest a theme-independent Template::Toolkit 
include directory, but that’s another story…)


David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

Office: 02 9212 0899

Online: 02 8005 0595


___
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/



--
Julian Maurice
BibLibre
___
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/

Re: [Koha-devel] Optimizing Starman startup

[Julian Maurice]

Le 21/04/2021 à 09:26, dc...@prosentient.com.au a écrit :
I recall someone (Julian or Kyle?) did some work to make Koha into a 
Mojolicious application


Yes, since 20.11 Koha can be started as a Mojolicious application.

`hypnotoad bin/intranet`

But you'll probably need 
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26625 in order 
to configure the listen port/address.


--
Julian Maurice
BibLibre
___
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/

Re: [Koha-devel] Rolling DB upgrades

[Julian Maurice]

Le 03/03/2021 à 11:18, Joonas Kylmälä a écrit :

Not really sure it is more work than writing the current db upgrade
procedures, maybe tiny bit, and a bit more if you want to be able to
revert the DB upgrade as well (which is optional and I don't think we
should even consider that for MVP implementation of this).


You at least need to modify the code so that it handles the intermediary 
state, don't you ?
In the case of a column/table rename, you need to make sure both 
columns/tables stay in sync until the whole upgrade process is finished.


--
Julian Maurice
BibLibre
___
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/

Re: [Koha-devel] Rolling DB upgrades

[Julian Maurice]

Le 03/03/2021 à 09:44, Joonas Kylmälä a écrit :

I don't know any other software but not sure it is that difficult. What
I gather, we could use e.g. Jenkins to push the code / new debian
package that would be created for every commit. Jenkins would make sure
db schema migration is finished before installing a newer version and
the steps would be repeated until we are at the latest release.


I'm not too much concerned about the "push-test-release" process, but 
more about how we consistently make the code aware of the multiple 
possible database states. Surely we'd have to enforce a new set of rules 
for writing database updates. And we'd have to test these changes very 
carefully, since a tiny mistake could mean a loss of data. Of course you 
have backups, but DB rollback means downtime, right ?
So, that sounds like a lot of extra work for avoiding a few seconds of 
downtime (most of the time).
That being said, I'm really interested in seeing an actual working 
implementation :)


Also, what about template translations ? It takes some time to generate 
translated templates, and it can do weird things if the new code is used 
while using the old templates (or the old code with the new templates). 
Wouldn't that prevent zero-downtime upgrade ?


--
Julian Maurice
BibLibre
___
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/

Re: [Koha-devel] Rolling DB upgrades

[Julian Maurice]

Le 02/03/2021 à 16:00, Joonas Kylmälä a écrit :

With rolling upgrade we would first create another
column with the new name and write & read data to both columns during
the 1st step of upgrade, then in 2nd step when all web server nodes are
using latest version we could upgrade again to newer version and just
delete the old column and start using new one.


Does it mean that the application (Perl) code should be aware of that 
intermediary state where both columns exist at the same time ? If so, 
for how long should it be aware of that old database state ?


Does it mean that, for every database schema update, you have to do 
something like this:

- git reset --hard commit_for_1st_step
- updatedatabase (add new column) && reload starman
- git reset --hard commit_for_2nd_step
- updatedatabase (remove old column) && reload starman
?

Do you know another open source software that allows rolling upgrade ? 
It seems like a great idea, but from what I just read online it looks 
really hard to do it correctly.


--
Julian Maurice
BibLibre
___
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/

Re: [Koha-devel] Location of plugins in @INC

[Julian Maurice]

Le 11/11/2020 à 01:17, dc...@prosentient.com.au a écrit :

Hi all,

I was talking about how we could override default Koha modules with 
customized versions by just making sure those modules were located 
earlier in @INC.


That got me thinking… at the moment we put Koha Plugins at the bottom of 
@INC, but we could actually put them at the start of @INC.


They would be more dangerous as they’d be able to override any Perl 
module… but they would also be more powerful.


More powerful, and quite impossible to maintain, as every change to the 
module would have to be done in the plugin as well :/

Also, two plugins overriding the same module... It just won't work.



In the context of a Koha where controllers are Perl modules (e.g. 
Mojolicious controllers) rather than Perl scripts, a plugin could 
override any controller in Koha. That could make for very powerful and 
seamless customizations.


For this particular use case I think there are better options, like 
giving plugins access to the Mojolicious router, which allows to 
override some routes.
Also note that Mojolicious has its own plugin system that can be used as 
well. For now the list of plugins used by Mojolicious applications is 
static, but it certainly can be made dynamic without much effort.


--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] New 'configurations' table (26129)

[Julian Maurice]

Hi Tomas,

I can see the benefits of a per-library, per-itemtype, per-category 
configuration table, but SMTP and Z39.50 servers do not seem to be the 
best example for that : "per-itemtype SMTP servers" does not make sense 
at all, and why would someone need per-library Z39.50 servers ?

Do you have other examples in mind ?

Will the per-category setting rely on the category of the logged-in user 
or the category of the user being worked on (patron checking out an item 
for instance) ? Will it depend on the setting itself (some settings rely 
on the logged-in user, some other settings rely on the user being worked 
on) ? Will it depend on another setting (like item-level_itypes syspref) 
? Will that other setting be configurable per-library ? ...
I'm afraid we will end up with a "configuration hell", even worse than 
what we already have with global system preferences.
At least it should be very clear what each per-thing mean, and we should 
be really careful to not over-complicate configuration.

In this particular example, a `smtp_servers` table seems a lot more simple

Le 03/08/2020 à 19:59, Tomas Cohen Arazi a écrit :

TL;DR;
This email is for getting some feedback about a new table I'm proposing 
to add that implements a pattern I'm seeing more and more often as 
required: global, and per-library, per-item type and per-category 
settings. It can be easily extended with new constraints as well.


Hi all, I wanted to highlight bug 26129 [1] which proposes to add a new 
table, for storing configuration entries. It differs from the 
systempreferences table basically on the ability to set values with 
per-library, per-item type and per-category basis, as well as default 
catch-all.


It is the result of noticing that the smtp_servers table I was going to 
add on bug 22343 [2], could be easily generalized and could become useful.


If someone is willing to do it, we could migrate systempreferences into 
this new table, but that definitely deserves more thinking. The SMTP 
configuration page won't live in the sysprefs page, and so a way to 
differentiate them could be added.


One sample use of this configurations table, could be moving z39.50 
servers there.


[1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26129 
<https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26129>
[2] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22343 
<https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22343>


--
Tomás Cohen Arazi
Theke Solutions (http://theke.io <http://theke.io/>)
✆ +54 9351 3513384
GPG: B2F3C15F

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/



--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] JSON templates and translation

[Julian Maurice]

3/ Build JSON in Perl script/module, and use Koha::I18N's __() for 
translatable strings.


Le 17/07/2020 à 09:51, Fridolin SOMERS a écrit :> Hi,


We faced a bug on a JSON template broken by PO translation of the column 
"borrowernumber"

/koha-tmpl/intranet-tmpl/prog/en/modules/members/tables/members_results.tt

How could we avoid this ?

1/
Disable translation of JSON templates and JS caller must translate using 
_().


2/
Add a way to define string to translate in JSON templates, like _() in JS.

Best regards,



--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] An idea for consolidating staff interface header search forms

[Julian Maurice]

I'm personally not a big fan of the "single big file" approach. I find 
it difficult to navigate through, and can cause git conflicts more often.
Also, it means that all blocks need to be parsed by TT on every page. 
Maybe it doesn't affect performance too much (or maybe it affects 
performance in a good way), but it makes more sense to me to only 
include what's needed.


I'd try to use WRAPPER + PROCESS directives to achieve the same thing:

[%# acq-searches.inc %]
[% WRAPPER 'header.inc' %]
  [% PROCESS 'vendor-search.inc' %]
  [% PROCESS 'orders-search.inc' %]
[% END %]

[%# header.inc %]
[% search_tabs = [] %]

  
[% content %]
  
  
[% FOREACH tab IN search_tabs %]
  [% tab %]
[% END %]
  


[%# vendor-search.inc %]
...
[% search_tabs.push('Search vendors') %]

Not sure if it works or if it is better than your solution, I just 
thought about that while reading your code. It probably has downsides too.



Le 14/07/2020 à 02:58, Owen Leonard a écrit :

this looks good to me - why do you think it might not be worth pursuing?

No particular reason, I just wanted to get some opinions in case there
was a downside I wasn't seeing.


--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] An idea for consolidating staff interface header search forms

[Julian Maurice]

Le 13/07/2020 à 16:36, Owen Leonard a écrit :

Even with the t() macro the
labels are still not picked up for translation correctly.


What do you mean ? Translation works for me on your branch : 
https://pic.infini.fr/nqc3mEkM/mvaUg6k2.png


--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] An idea for consolidating staff interface header search forms

[Julian Maurice]

Hi,

You don't need bug 20988, you can already use the t() macro to make 
strings translatable


[% USE Koha %]
[% PROCESS 'i18n.inc' %]

[% catalog_searches = [
 { formid => 'circ_search', label => t('Check out') },
 { formid => 'checkin_search', label => t('Check in') },
 { formid => 'renew_search', label => t('Renew') },
 { formid => 'catalog_search', label => t('Search the catalog'), 
open => 1 },

] %]

Le 12/07/2020 à 14:19, Katrin Fischer a écrit :

Hi Owen,

I like the idea of centralizing this code a bit more.

I am not sure if bug 20988 will fix the translation issue, but maybe we
could work around it for the time being?

Maybe instead of using [% form.label | html %] we could use the
form.formid and translate that to labels. Then we'd also not have to
repeat the label descriptions in the search definitions for the
different use cases.

Hope that makes sense,

Katrin

On 09.07.20 19:25, Owen Leonard wrote:

I'm playing around with the idea of eliminating all the many search
form include files (serials-search.inc, cat-search.inc,
checking-search.inc, etc.) and replacing them with a single template
which can be processed in different ways.

For instance, in the circulation-home.tt template, "[% INCLUDE
'circ-search.inc' %]" would be replaced with "[% PROCESS
header_searches.inc searches="circulation_searches" %]"

In header_searches.inc (see https://gitlab.com/snippets/1994424), an
array of search forms and their labels would be output according to
the "searches" variable passed to the include file for processing.

Unfortunately this doesn't appear to be translatable, but Bug 20988
might make it possible.

Does this sound like a worthwhile pursuit? A sensible way to leverage
Template toolkit's functionality?

Thanks,

  -- Owen


___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/


--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Add Koha API Route to Proxy to Backend Service

[Julian Maurice]

Hi,

You probably already have nginx or apache that can redirect requests to 
the proper backend. Why do you need Koha to do that ?


Le 09/07/2020 à 13:49, dc...@prosentient.com.au a écrit :

Hi all,

I was chatting with lmstrand on IRC, and we both came up with separate 
features where we’d essentially want Koha to proxy our HTTP requests  to 
the Koha API endpoint to a backend service running on the Koha server.


What do people think about using the Koha HTTP API that way?

Or would it just make more sense to run up Kong (or another API gateway) 
on the Koha server, and use it to proxy HTTP requests to backend 
services running on the Koha server? I think in both our cases Koha is 
itself only tangentially related. (lmstrand’s is a SIP2 client daemon 
available over HTTPS, while mine is a OAI-PMH harvester daemon available 
over HTTPS)


The advantage of using the Koha API is that it keeps everything 
together. The disadvantage is that we might not want to use Koha to 
proxy requests?


The advantage of Kong is that it keeps a separation of concerns, Kong 
has a tonne of plugins that make working with APIs a great experience. 
The disadvantage is that it’s yet another dependency.


David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

Office: 02 9212 0899

Online: 02 8005 0595


___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/



--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Perl version requirement

[Julian Maurice]

rk if it’s
not a mess. Expect a user release within a year."

--

As for Perl 5.x versions, in the past, I've said let's stay
at 5.10 because of RHEL 6, but RHEL 6 is being retired
November 30, 2020 (with an "Extended Life Cycle Support
Add-On" available until June 30, 2024). I really don't think
we should be hamstrung by RHEL 6 anymore. RHEL 7 comes with
5.16 and RHEL 7's "Software Collections" can be used with
Perl 5.20 and Perl 5.24, although I don't think that the
RHEL 7 "Software Collections" can be used with the
#!/usr/bin/perl shebang (which would be used in CGI and
Plack's CGI emulation). That said, RHEL 8 is available now
and it comes with Perl 5.26.

Maybe we should just focus on Perl versions for supported
Debian/Ubuntu OSes, and if people want to use other OSes,
then they just need to upgrade to a newer version that
supports a newer Perl.

I think you can install Docker on RHEL 7, so that's another
consideration for people running Koha on non-Debian/Ubuntu
OSes. They can always just look at implementing a
container-based solution, which leverages Debian/Ubuntu as
the container OS.

So yeah... let's pick the lowest Perl on our supported
Debian/Ubuntu and have that be the minimum supported Perl.

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
From: Koha-devel
mailto:koha-devel-boun...@lists.koha-community.org>> On
Behalf Of Paul A
Sent: Thursday, 25 June 2020 9:00 AM
To: koha-devel@lists.koha-community.org
<mailto:koha-devel@lists.koha-community.org>
    Subject: Re: [Koha-devel] Perl version requirement

On 2020-06-24 1:15 p.m., Julian Maurice wrote:
 > Ah yes, I forgot about Xenial.
 >
 > Not sure if it is still supported.

Ubuntu 16.04.6 LTS (Xenial Xerus) was released February 28,
2019, has an "End of Standard Support" set at April 2021,
and "End of Life" of April
2024 -- where some package enhancements are ensured up to
the first of those dates, and *security* is ensured until
the second, i.e nearly another four years from now.

I obviously cannot speak for more than the organizations
with which I am involved, but basically we are all keeping
c++, php and perl based code on 16.04 LTS using Apache, and
have moved only python coding to 18.04.
However, we do use Nginx on 18.04 as a front end, proxying
to the 16.04 back ends. We are beginning to look at 20.04,
but first impressions of the transition are slightly painful.

As Mark mentions below, Xenial uses Perl 5.22.1-9ubuntu0.6.
I understand that the "1-9ubuntu0.6" denotes some fifty
patches and fixes on top of "basic 5.22" but not amounting
to 5.24. Just for completeness, 18.04 uses perl 5.26, and
20.04 comes with perl 5.30.  However, from what I have
heard, the perl 5 branch has very few deprecated, let alone
removed, details, so backwards compatibility is on a fairly
firm footing. In fact, a quick look at 5.22 and 5.26 show
very much the same patches, but of course this may not apply
to non-core modules.

Best -- Paul



The thing is, depending on where you
 > look, you find different informations:
 >
 > In the latest release notes:
 >
 > - 20.05.01 says that the recommended environments are
Debian stretch,
 > Debian buster or Ubuntu bionic, and requires Perl 5.10
 > - 19.11.07 says that the recommended environments are
Debian jessie,
 > Debian stretch, Debian buster or Ubuntu bionic and
requires Perl 5.10
 > - 19.05.12 says the the recommended environements are
Debian stretch
 > or Ubuntu bionic, and requires Perl 5.24 (it's strange
that an older
 > version of Koha require a newer version of Perl)
 >
 > On Jenkins, there is a "supported" tab that includes
Ubuntu xenial,
 > bionic and focal, and Debian jessie, stretch and bu

Re: [Koha-devel] Perl 7

[Julian Maurice]

Le 25/06/2020 à 06:26, dc...@prosentient.com.au a écrit :
The article is worth a read though. It points out a number of language 
aspects that have changed (e.g. bareword file handles, indirect object 
notation, etc), and we could actually work on eliminating those in our 
current code to bring Koha more in line with modern Perl.




Just a reminder that this bug exists : 
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21395 (Make 
perlcritic happy) and that it replaces most (but not all) of the 
bareword filehandle.
We can also add 
https://metacpan.org/pod/Perl::Critic::Policy::Objects::ProhibitIndirectSyntax 
to our default .perlcriticrc


--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Perl version requirement

[Julian Maurice]

Ah yes, I forgot about Xenial.

Not sure if it is still supported. The thing is, depending on where you 
look, you find different informations:


In the latest release notes:

- 20.05.01 says that the recommended environments are Debian stretch, 
Debian buster or Ubuntu bionic, and requires Perl 5.10
- 19.11.07 says that the recommended environments are Debian jessie, 
Debian stretch, Debian buster or Ubuntu bionic and requires Perl 5.10
- 19.05.12 says the the recommended environements are Debian stretch or 
Ubuntu bionic, and requires Perl 5.24 (it's strange that an older 
version of Koha require a newer version of Perl)


On Jenkins, there is a "supported" tab that includes Ubuntu xenial, 
bionic and focal, and Debian jessie, stretch and buster.


So it is not very clear.
Maybe we can include that information in Koha's source (in README ?) and 
make it the "single source of truth" ?


Le 24/06/2020 à 18:40, Mark Tompsett a écrit :

Greetings,

I apologize if this is a dumb question, but do we support Xenial (Ubuntu 
16.04) still? If so, then Julian Maurice's suggestion is a little over. 
Xenial has Perl 5.22 in it. If we don't support Xenial, then +1 for his 
suggestion of 5.24 as the Perl version to use.


GPML,
Mark Tompsett

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/



--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Perl version requirement

[Julian Maurice]

Debian and Ubuntu are the recommended systems, but are not required.
I think it's useful to know the Perl requirements for people that want 
to install Koha on other systems.


Le 24/06/2020 à 12:20, Fridolin SOMERS a écrit :

Hi,

Indeed, since minimum OS is Debian Stretch.
Is it even useful to tell Perl requirement ?

Best regards,

Le 24/06/2020 à 09:46, Julian Maurice a écrit :

Hi,

While reading the release notes for 20.05.01 I noticed that the 
minimum Perl version required is still 5.10.
However, we use the '/r' regex modifier which was introduced in 5.14. 
There may be other features that we use that are not in Perl 5.10.
Considering that even debian oldstable has Perl 5.24, it should be 
safe to raise the minimum required version to 5.24.

What do you think ?





--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] Perl version requirement

[Julian Maurice]

Hi,

While reading the release notes for 20.05.01 I noticed that the minimum 
Perl version required is still 5.10.
However, we use the '/r' regex modifier which was introduced in 5.14. 
There may be other features that we use that are not in Perl 5.10.
Considering that even debian oldstable has Perl 5.24, it should be safe 
to raise the minimum required version to 5.24.

What do you think ?

--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Adopting CPAN and Carton

[Julian Maurice]

Le 09/06/2020 à 15:47, Tomas Cohen Arazi a écrit :
I think we should use carton and/or local::lib, and bundle all the 
dependencies on build time.

Building a Docker image? Bundle all deps.
Building a Debian package? Bundle all deps (we already need to build 
things for specific perl versions)

Building a Snap/Flatpack? Bundlfe all deps


Bundle all deps in a Debian package ? It does not seem very 
"Debian-friendly" :-/




cpanm means installing globally and is possible, but why not just... 
bundle them.


cpanm can install locally 
(https://metacpan.org/pod/distribution/App-cpanminus/bin/cpanm#-L,-local-lib-contained)





El mar., 9 jun. 2020 a las 3:47, Julian Maurice 
(mailto:julian.maur...@biblibre.com>>) 
escribió:


I'm all for installing Perl modules directly from CPAN. I'm less sure
about Carton. Is it really needed ? I believe that `cpanm --installdeps
.` does the same thing.

Anyway, I think the first step would be to write documentation on
how to
use this installation method. Even if not adopted, it can't hurt anyone
to have an alternate method documented.
Can you write it ?

Le 09/06/2020 à 01:13, dc...@prosentient.com.au
<mailto:dc...@prosentient.com.au> a écrit :
 > It would mean that the Koha community would support "CPAN and
Carton" as an installation method or use it as *the* installation
method for Koha.
 >
 > David Cook
 > Systems Librarian
 > Prosentient Systems
 > 72/330 Wattle St
 > Ultimo, NSW 2007
 > Australia
 >
 > Office: 02 9212 0899
 > Online: 02 8005 0595
 >
 > -Original Message-
 > From: Koha-devel mailto:koha-devel-boun...@lists.koha-community.org>> On Behalf Of
Julian Maurice
 > Sent: Friday, 5 June 2020 5:12 PM
 > To: koha-devel@lists.koha-community.org
<mailto:koha-devel@lists.koha-community.org>
 > Subject: Re: [Koha-devel] Adopting CPAN and Carton
 >
 > Hi,
 >
 > As you said it is already feasible and very easy to do. So what
would it mean to "adopt CPAN and Carton" ?
 >
 > Le 05/06/2020 à 08:10, dc...@prosentient.com.au
<mailto:dc...@prosentient.com.au> a écrit :
 >> Now that I think about it, embedding the Perl modules in the Debian
 >> package could be problematic due to dependencies on C libraries.
 >> (Currently building Text::Bidi on an OpenSUSE system and it's taking
 >> forever.)
 >>
 >> I actually found it pretty challenging to read replies
interweaved in
 >> emails, so I might not respond to all that.
 >>
 >> But yeah I could see the most likely option being keeping the Debian
 >> packages the way they are and just having an alternative Carton
style.
 >> All that is needed for it really is changing the PERL5LIB
 >> environmental variable, so it would be easy enough to do.
 >>
 >> David Cook
 >> Systems Librarian
 >> Prosentient Systems
 >> 72/330 Wattle St
 >> Ultimo, NSW 2007
 >> Australia
 >>
 >> Office: 02 9212 0899
 >> Online: 02 8005 0595
 >>
 >> -Original Message-
 >> From: Victor Grousset/tuxayo mailto:vic...@tuxayo.net>>
 >> Sent: Friday, 5 June 2020 3:15 PM
 >> To: dc...@prosentient.com.au <mailto:dc...@prosentient.com.au>;
'Koha Devel'
 >> mailto:koha-devel@lists.koha-community.org>>
 >> Subject: Re: Adopting CPAN and Carton
 >>
 >> Hi o/
 >>
 >> On 20-06-05 02:18, dc...@prosentient.com.au
<mailto:dc...@prosentient.com.au> wrote:
 >>> What are people’s thoughts on CPAN and Carton (the Perl version of
 >>> Bundler, Composer, NPM, etc)?
 >>
 >> I hope that something like that would be on our reach. And that it
 >> will make the majority of the work done to support other Linux
 >> distributions, which would be amazing!
 >>
 >>> I like the idea as a way of more easily managing Perl dependencies
 >>> regardless of Linux distribution and version; in other words, we
 >>> could provide the same dependencies regardless of being on Debian
 >>> Jessie/Debian Stretch/Debian Buster or Ubuntu or Fedora or RHEL or
 >> OpenSUSE.
 >>>
 >>>
 >>>
 >>> I suppose the difficulty is how we do a community-friendly
deployment?
 >>> I see two main options:
 >>>
 >>>    1. Have the Debian package run “carton install”
automatically during
 >>>       install/upgrad

Re: [Koha-devel] Adopting CPAN and Carton

[Julian Maurice]

I'm all for installing Perl modules directly from CPAN. I'm less sure 
about Carton. Is it really needed ? I believe that `cpanm --installdeps 
.` does the same thing.


Anyway, I think the first step would be to write documentation on how to 
use this installation method. Even if not adopted, it can't hurt anyone 
to have an alternate method documented.

Can you write it ?

Le 09/06/2020 à 01:13, dc...@prosentient.com.au a écrit :

It would mean that the Koha community would support "CPAN and Carton" as an 
installation method or use it as *the* installation method for Koha.

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
From: Koha-devel  On Behalf Of 
Julian Maurice
Sent: Friday, 5 June 2020 5:12 PM
To: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] Adopting CPAN and Carton

Hi,

As you said it is already feasible and very easy to do. So what would it mean to 
"adopt CPAN and Carton" ?

Le 05/06/2020 à 08:10, dc...@prosentient.com.au a écrit :

Now that I think about it, embedding the Perl modules in the Debian
package could be problematic due to dependencies on C libraries.
(Currently building Text::Bidi on an OpenSUSE system and it's taking
forever.)

I actually found it pretty challenging to read replies interweaved in
emails, so I might not respond to all that.

But yeah I could see the most likely option being keeping the Debian
packages the way they are and just having an alternative Carton style.
All that is needed for it really is changing the PERL5LIB
environmental variable, so it would be easy enough to do.

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
From: Victor Grousset/tuxayo 
Sent: Friday, 5 June 2020 3:15 PM
To: dc...@prosentient.com.au; 'Koha Devel'

Subject: Re: Adopting CPAN and Carton

Hi o/

On 20-06-05 02:18, dc...@prosentient.com.au wrote:

What are people’s thoughts on CPAN and Carton (the Perl version of
Bundler, Composer, NPM, etc)?


I hope that something like that would be on our reach. And that it
will make the majority of the work done to support other Linux
distributions, which would be amazing!


I like the idea as a way of more easily managing Perl dependencies
regardless of Linux distribution and version; in other words, we
could provide the same dependencies regardless of being on Debian
Jessie/Debian Stretch/Debian Buster or Ubuntu or Fedora or RHEL or

OpenSUSE.


   


I suppose the difficulty is how we do a community-friendly deployment?
I see two main options:

   1. Have the Debian package run “carton install” automatically during
  install/upgrade
   1. This could be error prone and difficult to support…  2. Have
the Koha Debian Package Manager run “carton install” when
  building the package, and embed the Perl modules in the Koha package
   1. It’s unknown how much this would increase the size of the Koha
  package


Interesting, I hope such an unified way will be possible.
If not, is the following a valid option?
The current way of managing the perl dependencies for Debian doesn't change.
And a carton way of managing the perl dependencies will coexist. (does
it mean just maintaining the cpanfile? I guess I'm very very wrong
here) And packages for the other distros will use carton.

It would depend of which is more work:
Integrating and maintaining the use of carton in the Debian packages
Or Maintaining the "full" Debian packages in parallel.

And also how much is valued the fact that for Debian, the perl deps
comes from the repo? (we could keep the versions in sync with Debian,
see [1]) Subparts of this:
- value of Debian patches
- anything else???



I think retaining Debian packages is important, because we have a
number of non-Perl dependencies, and the Debian packages provide a
lot of very useful automation.


Thank for addressing the question of "If we can use Carton, why have
packages at all?"
I trust you and the others for that ^^" I have no idea of whether or
not packages are the best option compared to others. Does anyone have
feedback about the handling of applications with a lot of deps in
other languages than Perl? (that have something similar to Carton)




Personally, I’m moving away from packaging Perl dependencies as
Debian packages for non-Koha projects, because it makes porting the
projects to a newer version of the same OS much more difficult.



I know using Debian’s Perl packages have a lot of advantages, as
they’re tested, reviewed, and patched, but I think it might be time
to consider a change.


[1]The cpanfile could still evolve in sync with the Debian package
versions of the perl libs.
That doesn't address the point "patched" => are there a lot of patched
perl packages in Debian?
i.e. enough so that e

Re: [Koha-devel] Adopting CPAN and Carton

[Julian Maurice]

evel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/



--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Koha packaging problems (Deb10/Buster)

[Julian Maurice]

Hi,

With the 'distro' repo, won't we have incompatibility problems between 
the Koha version and the Perl modules versions ? For instance, if Koha 
18.11 and 19.11 require 2 different versions of Mojolicious, how would 
that be solved ?


Another option is to have one repository per Koha version, for instance:

deb http://debian.koha-community.org/koha_19.11 [stretch|buster|bionic|...]

or to add the Koha version to the distribution name

deb http://debian.koha-community.org/koha stretch/19.11

That way we can support every koha/distro combinations we want.

Le 10/03/2020 à 08:08, Mason James a écrit :

Hi Koha devs

We have a dependency problem with the release of debian-10 and the following 
packages. (debian-11 is ok)

  libmojolicious-perl
  libmojolicious-plugin-openapi-perl
  libyaml-libyaml-perl


The packages require specific versions to be built for specific debian 
releases, due to their dependencies.
This type of problem has occurred before: an example is the 
libcryptx-perl/ubuntu-16.04 bug. or elasicsearch with jessie...
  https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23128

The specifics of the dependency problem are quite complex so I wont bore you 
unless you really ask :)

It seems the best solution is to create a new 'distro' repo that contains a 
small number of additional distro-specific packages. This should allow us to 
support every type of koha/distro (and arch) combination


Here's an example of a Koha sources.list file...  (We can name the distro 
releases/aliases as we please)

  deb http://debian.koha-community.org/koha 
[19.05|19.11|stable|oldstable|oldoldstable] main
  deb http://debian.koha-community.org/distro 
[debian9|ubuntu16.04|bionic|ubuntu-oldstable|stable] main


FYI: It's possible to add the distro-specific packages to the existing 'koha' 
repo, but that should probably be avoided due to managing the extra complexity 
(its cleaner to separate the two repos imho)


Two other options...
  1/ use kc.org debian packages, with cpanminus (or similar) providing the 
distro specific packages (extra installation steps and complexity)
  2/ ignore the problem for now, and accept that older koha/distro combinations 
will be forced to break

Does anyone have any other solutions that I have missed, or a better solution 
even?


Cheers, Mason


___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/



--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Minimal docker images for Koha

[Julian Maurice]

I believe that the problems we have with Debian buster are mostly 
related to the versions of Perl modules shipped with debian packages. 
Since these Dockerfiles install all Perl modules from CPAN in their 
latest version, I think you will have the same problems with an older 
version of Debian.


URL rewrite in PSGI file is handy for development, but that shouldn't be 
used in production. Indeed, a reverse proxy is still required in 
production environments.


Please note that images produced by these Dockerfiles are not intended 
to be used in production. As I said in my first message, you should 
expect things to break ;)


Le 01/03/2020 à 05:19, Agustin Moyano a écrit :

Sorry.. seems I send it only to Julian.. here goes again

El sáb., 29 de febrero de 2020 19:15, Agustin Moyano 
mailto:agustinmoy...@theke.io>> escribió:


Hi Julian, great work!!

I've also been working (interruptedly) for a couple of months on a
docker version of Koha.

I focused on having as soon as possible a fully functional docker
version of Koha, and didn't worry too much about doing things the
docker way.. It's comforting to know you weren't tempted by de dark
side of the force!

I thought of having first a production ready docker much like
koha-testing-docker, and later split services into different
containers. That's why I really, really loved your implementation of
plack.psgi. URL rewrite in psgi brings independence day from Apache
much closer! \o/.

Just some thoughts:

  * Should you base your image on Debian buster? on
https://wiki.koha-community.org/wiki/Koha_on_Debian says "Note:
Debian 10 (Buster) is currently not recommended or supported,
work is in progress to rectify this situation."
  * Even if there's no need for reverse proxy, I wouldn't discard
having one on a separate container.. web servers like apache or
nginx deal much better with attacks than exposing the service on
it's own (First hand experience with a Java/Tomcat service I
made once)

(https://security.stackexchange.com/questions/209111/security-benefits-of-reverse-proxying-java-tomcat-webapps-locally)

But overall, great job!

PS: If you'd like to take a peek of what I've done, here's the repo:
https://gitlab.com/thekesolutions/koha-docker



--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Minimal docker images for Koha

[Julian Maurice]

I gave another try at multi-stage builds. It turns out you can tag the 
intermediate image by building them first with `docker build --target 
 ...` so my problem with multi-stage builds is gone :)


The result is an image of ~875MB. I pushed it on 
https://hub.docker.com/r/julianmaurice/koha with the tag master-slim


Le 19/02/2020 à 01:17, dc...@prosentient.com.au a écrit :
Mmm that’s a good point. The smaller attack surface is something I harp 
on about a lot when it comes to making minimal images. That’s actually 
led me down some very fun rabbit holes about operating systems and Linux 
in particular.


For instance, here’s the Dockerfile for ubuntu:latest. It’s actually 
quite minimal with the majority of the work being done by “ADD 
ubuntu-bionic-core-cloudimg-amd64-root.tar.gz /”, which can be found at 
https://partner-images.canonical.com/core/bionic/current/ubuntu-bionic-core-cloudimg-amd64-root.tar.gz. 
When you open that up, it’s just a small Ubuntu root file system. Now 
what does that get us? First I’ll backtrack.


When the host boots, GRUB 2 finds the desired Linux kernel, loads the 
kernel and the initramfs, and then transfers control to the kernel, 
which runs the initramfs’s /init script (which typically invokes systemd 
these days). That /init script finds the “real” root file system, mounts 
it, and then executes systemd on the real root file system, which acts 
as the init system and becomes our old faithful PID 1.


Obviously that process doesn’t correspond to a container’s lifecycle. 
When a container is started, the kernel is already running and the root 
file system is already mounted. There’s already kernel mode and user 
mode code running to manage the computer. Docker gives us isolation 
using Linux kernel features like cgroups and namespaces, and takes care 
of special file system cases like /dev, /proc/, and /sys for us.


So a person doesn’t need a whole OS file system just to run a single 
program in Docker.


However, in our case, it gets complicated quickly, since Koha needs 
MySQL client libraries, Zebra client libraries, and whatever other 
libraries and files our Perl modules need (DateTime leverages OS-level 
datetime files I think, there’s libxml, probably GD, etc.). If we were 
really thorough, we probably could get Koha running in a very minimal 
container, but it would take some work. It could be fun though.


David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

Office: 02 9212 0899

Direct: 02 8005 0595

*From:*Koha-devel  *On 
Behalf Of *Kyle Hall

*Sent:* Tuesday, 18 February 2020 10:43 PM
*To:* Julian Maurice 
*Cc:* koha-devel 
*Subject:* Re: [Koha-devel] Minimal docker images for Koha

This is fantastic Julian! The only thing I can contribute that hasn't 
already been said by you or David is to suggest taking a look at MiniDeb 
as a base image ( https://github.com/bitnami/minideb ). I would also 
suggest using quay.io <http://quay.io> to build and host your Docker 
images, as it has built in security scanning. I prefer minimal install 
images not for size reduction ( though it is nice ), but for the smaller 
attack surface they provide. Fewer things installed means fewer exploits 
available!


Kyle

---

http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )
Crawford County Federated Library System ( http://www.ccfls.org )

On Mon, Feb 17, 2020 at 12:59 PM Julian Maurice 
mailto:julian.maur...@biblibre.com>> wrote:


Hi all,

I've been playing with docker lately, and I tried to build a minimal
docker image for Koha. Here are the results.

My goals were:
* Install only required "things" to get Koha up and running, and
nothing
else (no testing or dev tools),
* No external dependencies except CPAN
* Follow Docker best practices as much as possible

The resulting images are here:
https://hub.docker.com/repository/docker/julianmaurice/koha

and the Dockerfiles are here:
https://github.com/jajm/koha-docker

A few things worth mentioning:

* I tried to build the smallest image possible by using alpine or perl
slim images at first but it was not that great, because the perl
version
shipped with those images is missing some libs, which cause
MARC::Charset to build a database of several hundreds MBs (which is
only
5MBs with a standard perl version). So I chose a more standard image
(debian:buster) as base.

* Koha doesn't work well when running with a perl version different
than
the system perl installed in /usr/bin/perl. For example, the
updatedatabase doesn't work when called from the web installer. This is
because Perl scripts are called directly as executable files, and
shebangs contain '/usr/bin/perl'. Same problem from
misc/translator/translate which calls tmpl_process3.pl
<http://tmpl_pro

Re: [Koha-devel] Minimal docker images for Koha

[Julian Maurice]

I just tried minideb, the resulting image weigh 1.1GB, right between 
debian:buster-slim and debian:buster


I did not found a free plan for quay.io (only a 30-day free trial). Does 
it have one ?


Le 18/02/2020 à 12:43, Kyle Hall a écrit :
This is fantastic Julian! The only thing I can contribute that hasn't 
already been said by you or David is to suggest taking a look at MiniDeb 
as a base image ( https://github.com/bitnami/minideb ). I would also 
suggest using quay.io <http://quay.io> to build and host your Docker 
images, as it has built in security scanning. I prefer minimal install 
images not for size reduction ( though it is nice ), but for the smaller 
attack surface they provide. Fewer things installed means fewer exploits 
available!


Kyle

---
http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )
Crawford County Federated Library System ( http://www.ccfls.org )


On Mon, Feb 17, 2020 at 12:59 PM Julian Maurice 
mailto:julian.maur...@biblibre.com>> wrote:


Hi all,

I've been playing with docker lately, and I tried to build a minimal
docker image for Koha. Here are the results.

My goals were:
* Install only required "things" to get Koha up and running, and
nothing
else (no testing or dev tools),
* No external dependencies except CPAN
* Follow Docker best practices as much as possible

The resulting images are here:
https://hub.docker.com/repository/docker/julianmaurice/koha

and the Dockerfiles are here:
https://github.com/jajm/koha-docker

A few things worth mentioning:

* I tried to build the smallest image possible by using alpine or perl
slim images at first but it was not that great, because the perl
version
shipped with those images is missing some libs, which cause
MARC::Charset to build a database of several hundreds MBs (which is
only
5MBs with a standard perl version). So I chose a more standard image
(debian:buster) as base.

* Koha doesn't work well when running with a perl version different
than
the system perl installed in /usr/bin/perl. For example, the
updatedatabase doesn't work when called from the web installer. This is
because Perl scripts are called directly as executable files, and
shebangs contain '/usr/bin/perl'. Same problem from
misc/translator/translate which calls tmpl_process3.pl
<http://tmpl_process3.pl>.

* I tried to make the Koha installation as self-contained as possible.
Almost everything is installed as a non-root user in /home/koha,
including Perl dependencies.

* It doesn't need a reverse proxy such as apache or nginx. The
necessary
URL rewriting is handled in PSGI file. The container expose two ports,
one for intranet, the other one for OPAC.

* Each Perl dependency is installed in its latest version, so expect
things to break. I can only confirm that the webinstaller, basic
cataloguing and search/indexation work. I did not test anything else.

* There are docker-compose.yml files in the github repository to get
Koha running quickly with mariadb, memcached and elasticsearch.

* Zebra is not installed

* Images weigh ~1.15GB uncompressed (koha sources included)

If you made it this far, thanks for reading :)
And if you want to use these docker images, you should start by reading
https://github.com/jajm/koha-docker/blob/master/README.md

-- 
Julian Maurice

BibLibre
___
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 : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/



--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Minimal docker images for Koha

[Julian Maurice]

Are you talking about these files
https://github.com/Koha-Community/Koha/blob/master/debian/templates/apache-shared-intranet-plack.conf#L14-L21 
?


I did nothing specific, so they are probably broken :)

Le 18/02/2020 à 12:45, Kyle Hall a écrit :
One other question, how does this handle scripts that Koha specifically 
does not execute using plack?


Kyle

---
http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )
Crawford County Federated Library System ( http://www.ccfls.org )


On Tue, Feb 18, 2020 at 6:43 AM Kyle Hall <mailto:kyle.m.h...@gmail.com>> wrote:


This is fantastic Julian! The only thing I can contribute that
hasn't already been said by you or David is to suggest taking a look
at MiniDeb as a base image ( https://github.com/bitnami/minideb ). I
would also suggest using quay.io <http://quay.io> to build and host
your Docker images, as it has built in security scanning. I prefer
minimal install images not for size reduction ( though it is nice ),
but for the smaller attack surface they provide. Fewer things
installed means fewer exploits available!

Kyle

---
http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )
Crawford County Federated Library System ( http://www.ccfls.org )


On Mon, Feb 17, 2020 at 12:59 PM Julian Maurice
mailto:julian.maur...@biblibre.com>>
wrote:

Hi all,

I've been playing with docker lately, and I tried to build a
minimal
docker image for Koha. Here are the results.

My goals were:
* Install only required "things" to get Koha up and running, and
nothing
else (no testing or dev tools),
* No external dependencies except CPAN
* Follow Docker best practices as much as possible

The resulting images are here:
https://hub.docker.com/repository/docker/julianmaurice/koha

and the Dockerfiles are here:
https://github.com/jajm/koha-docker

A few things worth mentioning:

* I tried to build the smallest image possible by using alpine
or perl
slim images at first but it was not that great, because the perl
version
shipped with those images is missing some libs, which cause
MARC::Charset to build a database of several hundreds MBs (which
is only
5MBs with a standard perl version). So I chose a more standard
image
(debian:buster) as base.

* Koha doesn't work well when running with a perl version
different than
the system perl installed in /usr/bin/perl. For example, the
updatedatabase doesn't work when called from the web installer.
This is
because Perl scripts are called directly as executable files, and
shebangs contain '/usr/bin/perl'. Same problem from
misc/translator/translate which calls tmpl_process3.pl
<http://tmpl_process3.pl>.

* I tried to make the Koha installation as self-contained as
possible.
Almost everything is installed as a non-root user in /home/koha,
including Perl dependencies.

* It doesn't need a reverse proxy such as apache or nginx. The
necessary
URL rewriting is handled in PSGI file. The container expose two
ports,
one for intranet, the other one for OPAC.

* Each Perl dependency is installed in its latest version, so
expect
things to break. I can only confirm that the webinstaller, basic
cataloguing and search/indexation work. I did not test anything
else.

* There are docker-compose.yml files in the github repository to
get
Koha running quickly with mariadb, memcached and elasticsearch.

* Zebra is not installed

* Images weigh ~1.15GB uncompressed (koha sources included)

If you made it this far, thanks for reading :)
And if you want to use these docker images, you should start by
reading
https://github.com/jajm/koha-docker/blob/master/README.md

-- 
Julian Maurice

BibLibre
___
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 : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/



--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-communi

Re: [Koha-devel] Minimal docker images for Koha

[Julian Maurice]

Le Tue, 18 Feb 2020 17:29:42 +1100,
 a écrit :

> I was actually wondering earlier how many packaged dependencies Koha
> really has. Off the top of my head, I think the main ones are Apache
> httpd, Zebra/YAZ, and Mysql client libraries. It looks like "unzip"
> is needed as well. A number of the other dependencies like
> xmlstarlet, tinymce, libjs-jquery, mysql, etc are just for the Debian
> packages. (Actually, I think there is a mysql client binary use in
> one of the unit tests which seems suboptimal.) Oh, and due to your
> use of that static file middleware, Apache httpd isn't even needed. A
> person could probably run the Zebra server in a different container,
> share a mounted volume for the data, and then just have Zebra/yaz
> client software in the Koha container. Or if you went the
> Elasticsearch route, you wouldn't need Zebra at all, right? So in
> theory you could maybe get away just with "unzip" as a dependency
> that needs installing via a package manager? (Technically, we could
> use pure Perl unzip modules as well...)

What is unzip needed for ?

I didn't think of volumes for Zebra. That's a great idea. I might try
that later.
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Minimal docker images for Koha

[Julian Maurice]

The correct URL is indeed https://hub.docker.com/r/julianmaurice/koha
Sorry for that :)

I just tried buster-slim. The resulting image is 1.06GB. That's ~100MB 
less than with buster, not bad. But the debian page on dockerhub also 
states that "These tags are an experiment [...] and are definitely 
subject to change" so I prefer to stay on the non-slim variant for now.


I also tried multi-stage builds, but I didn't like the fact that it 
leaves an untagged image after each build.
Also I figured we might need the build tools once in the container, to 
install a missing Perl module for instance.
And to be honest, after the "failures" of alpine and perl-slim, I 
decided it was not worth it to try to build the smallest image possible.
But you're right, using multi-stage builds we can further reduce the 
final image size.


And if you really really want the smallest image, I think you should use 
alpine and recompile perl with the correct flags to avoid the 
MARC::Charset problem. I estimated that you could have an image of 800MB 
or less.


About mounted volumes, from what I understand volumes are for mutable 
data, and it's considered bad practice to use them for anything else.


I would really like to see a non-Debian based image of Koha. It should 
be relatively easy to do so, by replacing the apt-get command with the 
corresponding one for OpenSUSE.


Le 18/02/2020 à 01:25, dc...@prosentient.com.au a écrit :

Hi Julian,

Awesome to see you playing with Docker. I love Docker and I've been thinking 
about assembling similar Docker images for Koha, but haven't had the time, so 
hurray for you doing it!

I couldn't get your first URL to work as I think that's an authorised user 
link. Is it safe to say that this is the public link? 
https://hub.docker.com/r/julianmaurice/koha

Did you try the "debian:buster-slim" image? I keep meaning to look to see what 
makes these Koha images so large. With an interpreted language like Perl and Koha's 
immense functionality, I think it would be challenging to get a small image size. 
RedHat's registry.access.redhat.com/ubi8/perl-526 image is 658MB and that's without 
anything application specific even installed.

That being said, I think I see some places where you could improve your Dockerfile. Have 
you checked out multi-stage builds at 
https://docs.docker.com/develop/develop-images/multistage-build/? In your final image, 
you shouldn't need packages like gcc, git, *-dev, make, cpanm, etc. You can install those 
in a "builder" image and do the Koha build there. Then you can copy your Perl 
libraries and built Koha into the final image. That should also help you cut down on the 
number of layers you have.

Nice work identifying those system perl dependencies. I keep thinking how we 
should minimize those. It should be reasonably easy to fix those.

Actually, if Koha and its Perl dependencies are localized, you could override 
those with a mounted volume... which makes me wonder why you couldn't use a 
more minimal Linux...

I've actually been meaning to make some OpenSUSE Koha images which would help 
test out the concept of a minimal Koha running on something other than Debian 
as well, although one may as well use Debian, since that's the supported OS for 
Koha...

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

-Original Message-
From: Koha-devel  On Behalf Of 
Julian Maurice
Sent: Tuesday, 18 February 2020 4:59 AM
To: koha-devel 
Subject: [Koha-devel] Minimal docker images for Koha

Hi all,

I've been playing with docker lately, and I tried to build a minimal docker 
image for Koha. Here are the results.

My goals were:
* Install only required "things" to get Koha up and running, and nothing else 
(no testing or dev tools),
* No external dependencies except CPAN
* Follow Docker best practices as much as possible

The resulting images are here:
https://hub.docker.com/repository/docker/julianmaurice/koha

and the Dockerfiles are here:
https://github.com/jajm/koha-docker

A few things worth mentioning:

* I tried to build the smallest image possible by using alpine or perl slim 
images at first but it was not that great, because the perl version shipped 
with those images is missing some libs, which cause MARC::Charset to build a 
database of several hundreds MBs (which is only 5MBs with a standard perl 
version). So I chose a more standard image
(debian:buster) as base.

* Koha doesn't work well when running with a perl version different than the 
system perl installed in /usr/bin/perl. For example, the updatedatabase doesn't 
work when called from the web installer. This is because Perl scripts are 
called directly as executable files, and shebangs contain '/usr/bin/perl'. Same 
problem from misc/translator/translate which calls tmpl_process3.pl.

* I tried to make the Koha installation as self-contained as poss

[Koha-devel] Minimal docker images for Koha

[Julian Maurice]

Hi all,

I've been playing with docker lately, and I tried to build a minimal 
docker image for Koha. Here are the results.


My goals were:
* Install only required "things" to get Koha up and running, and nothing 
else (no testing or dev tools),

* No external dependencies except CPAN
* Follow Docker best practices as much as possible

The resulting images are here:
  https://hub.docker.com/repository/docker/julianmaurice/koha

and the Dockerfiles are here:
  https://github.com/jajm/koha-docker

A few things worth mentioning:

* I tried to build the smallest image possible by using alpine or perl 
slim images at first but it was not that great, because the perl version 
shipped with those images is missing some libs, which cause 
MARC::Charset to build a database of several hundreds MBs (which is only 
5MBs with a standard perl version). So I chose a more standard image 
(debian:buster) as base.


* Koha doesn't work well when running with a perl version different than 
the system perl installed in /usr/bin/perl. For example, the 
updatedatabase doesn't work when called from the web installer. This is 
because Perl scripts are called directly as executable files, and 
shebangs contain '/usr/bin/perl'. Same problem from 
misc/translator/translate which calls tmpl_process3.pl.


* I tried to make the Koha installation as self-contained as possible. 
Almost everything is installed as a non-root user in /home/koha, 
including Perl dependencies.


* It doesn't need a reverse proxy such as apache or nginx. The necessary 
URL rewriting is handled in PSGI file. The container expose two ports, 
one for intranet, the other one for OPAC.


* Each Perl dependency is installed in its latest version, so expect 
things to break. I can only confirm that the webinstaller, basic 
cataloguing and search/indexation work. I did not test anything else.


* There are docker-compose.yml files in the github repository to get 
Koha running quickly with mariadb, memcached and elasticsearch.


* Zebra is not installed

* Images weigh ~1.15GB uncompressed (koha sources included)

If you made it this far, thanks for reading :)
And if you want to use these docker images, you should start by reading 
https://github.com/jajm/koha-docker/blob/master/README.md


--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Bug 18936 - Circulation Rules Ratification

[Julian Maurice]

I can easily understand why the commit messages were not revised, and I 
certainly wouldn't want to be the person that delay such an important 
patchset because of the commit messages.


The problem with commit messages is that they cannot be changed/improved 
after the commits have been pushed. And as you said, follow-ups often 
pollute the history.


Also, it may be easier to enforce a rule like "you have to write one 
line in ChangeLog" than a rule like "you have to write a good commit 
message" because good and bad are really subjective. And if the line in 
ChangeLog is not good enough, it can still be improved later, after the 
commits are pushed.


Maybe we can continue this discussion on bug 22890, as Jonathan suggested

Le 05/02/2020 à 09:47, Joonas Kylmälä a écrit :

Hi,

if you are still interested to know the why part, it is explained in the
wiki:
<https://wiki.koha-community.org/wiki/Circulation_Rules_Interface_and_Backend_Revamp_RFC>.
I definitely agree it should have been in the commits too but I got
maybe too lax as a QA person since we had so many regressions fixed
already (took around 2 weeks to do the QA) the earliest patches were
send and revised already 2.5 years ago so this has been a long process
but I guess not a real excuse either.

As for the developer changelog, I'm fine with reading just the git
history but for this to work ideally I still think the follow-ups from
the patch author itself are bad and we need to be strict about enforcing
good commit messages!

On 04/02/2020 18:58, Julian Maurice wrote:

Thanks for the clarification, but my comment was more about "how people
could find this information" rather than "give me this information".
Currently it's not in the bug, not in commit messages, not in any kind
of documentation.

During the last developer irc meeting it was decided to reinforce good
commit message guideline, and I think that could have been useful here.
Specifically the "why" part is missing and the "what" part could have
been more verbose.

Apart from this particular bug, I think everyone would benefit from a
"developer changelog" where all this kind of changes (database renames,
subroutines removals, ...) would be written.

Just my 2 cents...

PS: Not everyone has time to look at all the bugs discussed on the
mailing list. Please don't make me feel guilty about it :)


--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Koha mirror on gitlab.com not updated ?

[Julian Maurice]

I know there is a mirror on github but the koha-community organization 
there has only 4 repositories, including one which points to gitlab.com 
(kohadocs), and another that is not directly related to koha (perlweb).
If we compare to gitlab.com where there are 17 repositories, I think we 
cannot say that we "moved" to github.


So, the situation is a little weird as almost all repositories are on 
gitlab, except for the main repository which is not updated correctly, 
so people have to go elsewhere (github or git.koha-community.org) to get 
koha


Hopefully gitlab will fix the issue. But what if they don't ? :/

Le 05/02/2020 à 10:00, Jonathan Druart a écrit :

Have you considered moving to github instead ? (github has a hard limit
of 100GB per repository)


We moved from github to gitlab a couple of years ago ;)



Le 04/02/2020 à 16:29, Jonathan Druart a écrit :

I investigated that issue few months ago, and asked Chris what
returned `du -sbh .git` on git.koha-community.org/koha: 2.8G.git
So it's really weird that gitlab complains about that size (13GB)
At that time (June 2019) the gitlab interface says "17Go, 7 over the
limit of 10."
So numbers look quite inconsistent.

See also the issue I opened on their bug tracker:
https://gitlab.com/gitlab-com/support-forum/issues/4590



Le mar. 4 févr. 2020 à 15:28, Julian Maurice
 a écrit :


Can we do something about that or should we consider the mirror on
gitlab to be useless and never use it ?

Le 04/02/2020 à 14:59, Tomas Cohen Arazi a écrit :

Because of Koha's repo size.

El mar., 4 feb. 2020 a las 10:55, Julian Maurice
(mailto:julian.maur...@biblibre.com>>)
escribió:

  Hi all,

  It seems the mirror on gitlab is not updated anymore. The last
  commit on
  master is

  604c7b81 Bug 22816: OPAC detail holdings table should now look a bit
  better

  which has been committed in May 2019

  Does anyone know why ?

      --
  Julian Maurice
  BibLibre
  ___
  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 : http://www.koha-community.org/
  git : http://git.koha-community.org/
  bugs : http://bugs.koha-community.org/



--
Tomás Cohen Arazi
Theke Solutions (http://theke.io <http://theke.io/>)
✆ +54 9351 3513384
GPG: B2F3C15F


--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/


--
Julian Maurice
BibLibre


--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Bug 18936 - Circulation Rules Ratification

[Julian Maurice]

Thanks for the clarification, but my comment was more about "how people 
could find this information" rather than "give me this information". 
Currently it's not in the bug, not in commit messages, not in any kind 
of documentation.


During the last developer irc meeting it was decided to reinforce good 
commit message guideline, and I think that could have been useful here. 
Specifically the "why" part is missing and the "what" part could have 
been more verbose.


Apart from this particular bug, I think everyone would benefit from a 
"developer changelog" where all this kind of changes (database renames, 
subroutines removals, ...) would be written.


Just my 2 cents...

PS: Not everyone has time to look at all the bugs discussed on the 
mailing list. Please don't make me feel guilty about it :)


Le 04/02/2020 à 16:40, Jonathan Druart a écrit :

Bug 18936 is the groundwork for bug 15522 (revamp issuing rules interface).

Everybody should have heard about it as the mailing list contains
several occurrences of this work: ask for help, signoff/QA, as well as
the different call for the proposal, starting 4 years ago.

Bug 18936 does not bring anything to the end-user, but basically you
just need to keep in mind that:
- the issuingrules table does not longer exist (!)
- rules are now in the circulation_rules, which has the following
structure: branchcode, categorycode, itemtype, rule_name, rule_value
(so 1 row per rule)
- you should call Koha::CirculationRules->set_rule (single) or
set_rules (multiple) to define/set circulation rules
- the rebase was painful and I apologized in advance for the issues I
left behind :)
- bug 15522 is on its way, and it would be really useful to get more
testing on it!

Cheers


Le mar. 4 févr. 2020 à 14:25, Julian Maurice
 a écrit :


Hi Martin,

I just discovered this bug and, after reading quickly the bug's comments
and commit messages, I didn't find the reason of this big refactoring
(why was it needed ? what do we gain ? is it only a rename or is it more
than that ?). Is this explained somewhere ?

In my opinion changes should be summarized at least in the first commit
message, so that people rebasing other patches can have an overview of
what changes are needed in their patches.

Le 04/02/2020 à 11:01, Renvoize, Martin a écrit :

Hi All,

I just wanted to let you all know that I'll be pushing bug 18936 to the
master branch this morning. It's the largest to date of the refactoring
bugs and will affect any/all bugs related to the circulation rules handling.

It's been thoroughly tested and QA'd, but as a large piece I'm sure
there will be a few pain points still buried, so keep an eye out and
report any bugs you find.

Good luck with any rebases that may be required after this and my
apologies, but the end result should give us a much cleaner foundation
for circ related enhancements and cleanup in the future.

Many thanks to those who have spent many hours coding, testing, refining
and qaing this piece,

*Martin Renvoize*



<https://www.ptfs-europe.com>

Development Team Manager

Community Release Manager (19.11, 20.05)


*Phone:* +44 (0) 1483 378728



*Mobile:* +44 (0) 7725 985 636

*Email:* martin.renvo...@ptfs-europe.com
<mailto:martin.renvo...@ptfs-europe.com>



*Fax:* +44 (0) 800 756 6384




www.ptfs-europe.com <https://www.ptfs-europe.com>

Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30


The information contained in this email message may be privileged,
confidential and protected from disclosure. If you are not the intended
recipient, any dissemination, distribution or copying is strictly
prohibited. If you think that you have received this email message in
error, please email the sender at i...@ptfs-europe.com
<mailto:i...@ptfs-europe.com>




___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/



--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/


--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Koha mirror on gitlab.com not updated ?

[Julian Maurice]

7 months without an answer from GitLab support... :/

Have you considered moving to github instead ? (github has a hard limit 
of 100GB per repository)


Le 04/02/2020 à 16:29, Jonathan Druart a écrit :

I investigated that issue few months ago, and asked Chris what
returned `du -sbh .git` on git.koha-community.org/koha: 2.8G.git
So it's really weird that gitlab complains about that size (13GB)
At that time (June 2019) the gitlab interface says "17Go, 7 over the
limit of 10."
So numbers look quite inconsistent.

See also the issue I opened on their bug tracker:
https://gitlab.com/gitlab-com/support-forum/issues/4590



Le mar. 4 févr. 2020 à 15:28, Julian Maurice
 a écrit :


Can we do something about that or should we consider the mirror on
gitlab to be useless and never use it ?

Le 04/02/2020 à 14:59, Tomas Cohen Arazi a écrit :

Because of Koha's repo size.

El mar., 4 feb. 2020 a las 10:55, Julian Maurice
(mailto:julian.maur...@biblibre.com>>)
escribió:

 Hi all,

 It seems the mirror on gitlab is not updated anymore. The last
 commit on
 master is

 604c7b81 Bug 22816: OPAC detail holdings table should now look a bit
 better

 which has been committed in May 2019

 Does anyone know why ?

     --
     Julian Maurice
 BibLibre
 ___
 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 : http://www.koha-community.org/
 git : http://git.koha-community.org/
 bugs : http://bugs.koha-community.org/



--
Tomás Cohen Arazi
Theke Solutions (http://theke.io <http://theke.io/>)
✆ +54 9351 3513384
GPG: B2F3C15F


--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/


--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Koha mirror on gitlab.com not updated ?

[Julian Maurice]

Can we do something about that or should we consider the mirror on 
gitlab to be useless and never use it ?


Le 04/02/2020 à 14:59, Tomas Cohen Arazi a écrit :

Because of Koha's repo size.

El mar., 4 feb. 2020 a las 10:55, Julian Maurice 
(mailto:julian.maur...@biblibre.com>>) 
escribió:


Hi all,

It seems the mirror on gitlab is not updated anymore. The last
commit on
master is

604c7b81 Bug 22816: OPAC detail holdings table should now look a bit
better

which has been committed in May 2019

Does anyone know why ?

-- 
Julian Maurice

BibLibre
___
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 : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/



--
Tomás Cohen Arazi
Theke Solutions (http://theke.io <http://theke.io/>)
✆ +54 9351 3513384
GPG: B2F3C15F


--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] Koha mirror on gitlab.com not updated ?

[Julian Maurice]

Hi all,

It seems the mirror on gitlab is not updated anymore. The last commit on 
master is


604c7b81 Bug 22816: OPAC detail holdings table should now look a bit better

which has been committed in May 2019

Does anyone know why ?

--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Bug 18936 - Circulation Rules Ratification

[Julian Maurice]

Hi Martin,

I just discovered this bug and, after reading quickly the bug's comments 
and commit messages, I didn't find the reason of this big refactoring 
(why was it needed ? what do we gain ? is it only a rename or is it more 
than that ?). Is this explained somewhere ?


In my opinion changes should be summarized at least in the first commit 
message, so that people rebasing other patches can have an overview of 
what changes are needed in their patches.


Le 04/02/2020 à 11:01, Renvoize, Martin a écrit :

Hi All,

I just wanted to let you all know that I'll be pushing bug 18936 to the 
master branch this morning. It's the largest to date of the refactoring 
bugs and will affect any/all bugs related to the circulation rules handling.


It's been thoroughly tested and QA'd, but as a large piece I'm sure 
there will be a few pain points still buried, so keep an eye out and 
report any bugs you find.


Good luck with any rebases that may be required after this and my 
apologies, but the end result should give us a much cleaner foundation 
for circ related enhancements and cleanup in the future.


Many thanks to those who have spent many hours coding, testing, refining 
and qaing this piece,


*Martin Renvoize*



<https://www.ptfs-europe.com>

Development Team Manager

Community Release Manager (19.11, 20.05)


*Phone:* +44 (0) 1483 378728



*Mobile:* +44 (0) 7725 985 636

*Email:* martin.renvo...@ptfs-europe.com 
<mailto:martin.renvo...@ptfs-europe.com>




*Fax:* +44 (0) 800 756 6384




www.ptfs-europe.com <https://www.ptfs-europe.com>

Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30


The information contained in this email message may be privileged, 
confidential and protected from disclosure. If you are not the intended 
recipient, any dissemination, distribution or copying is strictly 
prohibited. If you think that you have received this email message in 
error, please email the sender at i...@ptfs-europe.com 
<mailto:i...@ptfs-europe.com>





___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/



--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Koha, jump

[Julian Maurice]

Hi Jonathan,

Thank you for the screencast, I really had no idea of what you were 
talking about before watching it :)


I think it's a great idea. I use something similar [1] to launch 
programs and navigate between my open windows and it's really useful.


Quick thoughts:
- Jumping around with only a few keystrokes will surely be useful but 
I'm less sure about the creation part (wouldn't it be easier to jump to 
the creation page, and then fill the form ?)
- This is something that would benefit from being extendable by other 
plugins (add other jump locations, add other actions, ...). It might 
prevent the main plugin to become too complex.

- "go" is faster to type than "jump" ;)
- A "set/get" action for sysprefs would be really useful
- It looks like it's designed to act on/jump to DB entries, would it be 
easy to add a static list to jump to (like the list of tools, or the 
list of administration pages) ?
- fuzzy matching can be convenient if the number of available actions 
starts to grow


Be sure I'll try the plugin whenever I find the time ;)

[1] https://github.com/davatorium/rofi

Le 27/12/2019 à 13:59, Jonathan Druart a écrit :

Hi devs,

I have been spending some hours on a plugin lately. The plan was to
understand a bit the new capabilities that were added recently.
Also I wanted to quickly implement an idea I had few weeks ago.
So far everything is dirty, but I wanted to share it as soon as I had
something that was more or less working.

The plugin is named "koha-plugin-jump" and is available on my gitlab repository.
 From the README:
"""
It started with a simple idea then it got complex, as always. So far
the UI, the design and the code are ugly.
The first idea was to add a simple method to jump from one page to
another, then came the idea to generate data on demand, then data that
matches given conditions, then etc.
What's possible so far:
  * Jump to the following entities: biblio, item, itemtype, libraries,
list (shelves)
  * Create one of those entities, with or without attributes of your choices
Example:
  * jump biblio The art of will display the list of bibliographic
records matching "The art of" in their title, when selected you will
be redirected to the selected record
  * create item will create a new item
  * create 10 item biblionumber=20 will create 10 items attached to the
bibliographic record with the biblionnumber=20
"""

I cannot continue to develop alone this plugin so I would love to get
some help on it, if you think it could be helpful to you as well.

To install it you will have to generate the kpz file (not released
using the gitlab workflow yet):
% git clone https://gitlab.com/joubu/koha-plugin-jump
% cd koha-plugin-jump
% zip -r koha-plugin-jump.kpz Koha
Then install the kpz using the Koha plugin tool page.

Also if you want pretty data to be generated you should use patches
from bug 24310 (do not forget to install libtext-lorem-perl)

If you are lazy to try it, you can have a look at this screencast:
https://drive.google.com/open?id=1G01pr8IZH2m5W7_bxEibfi3MyzXAZF-5 (I
have no idea why this stuff rendered so dark!)

Enjoy end 2019 ;)

Cheers,
Jonathan

https://gitlab.com/joubu/koha-plugin-jump
https://gitlab.com/joubu/koha-plugin-jump/blob/master/README.md
https://gitlab.com/joubu/koha-plugin-jump/blob/master/TODO
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/



--
Julian Maurice
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] Bug 15395: Internationalization, plural forms, context and more

[Julian Maurice]

Hi all,

This bug has been signed off more than a year ago but it is still not
Passed QA. It seems that not everyone agree on it. It should probably be
discussed during an IRC meeting, but in the meantime, I wrote a wiki
page [1] to better explain what it is supposed to do and created a
thread on framavox [2] to gather opinions.

If you have some time, I would really appreciate feedback on this feature.
Thanks.

[1]
https://wiki.koha-community.org/wiki/Internationalization,_plural_forms,_context,_and_more_RFC
[2]
https://framavox.org/d/2juWqIMz/internationalization-plural-forms-context-and-more

PS: framavox.org is a free software (Loomio) hosted by a French
association (Framasoft) promoting free software. It only requires an
e-mail address to create an account.

-- 
Julian Maurice 
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] git trailers: should we use more of them ?

[Julian Maurice]

I've added a section in
https://wiki.koha-community.org/wiki/Commit_messages to encourage people
adding more informations to commits.
Changing Signed-off-by seems to be a bad idea. So let's do nothing about
this.

What about the QA signoff ? Reviewed-by or not ?

Le 25/09/2018 à 08:04, Renvoize, Martin a écrit :
> I agree to the idea in principle too, adding detail is great.
> 
> I don't have an issue with misusing the signoff line, I've been aware of
> that distinction for a long time. The major advantage of using it for
> our workflow is that it's often the least technical user doing the
> initial signoff and as such having the -s shortcut built into git is a
> nice aid.  I don't see any similar flags for the other options.
> 
> I can see it leading to the opportunity to really improve our history
> and about pages along with more recognition in release notes.
> 
> Just my two pence.
> 
> On Thu, 20 Sep 2018, 6:56 pm Katrin Fischer,  <mailto:katrin.fischer...@web.de>> wrote:
> 
> I think we'd need to change a lot of things if we switched from
> Signed-off-by to another - including a lot of documentation. It
> might add more confusion than doing good imo. But I'd be OK with
> changing the line for QA to make things more clear if that is what
> people would like to see. Also using some additional ones like
> Mentored-by could be useful.
> 
> Katrin
> 
> 
> On 19.09.2018 20:51, Tomas Cohen Arazi wrote:
>> I like the idea of adding more uses. Mentored-by is interesting
>> information on the QA step, for example.
>>
>> El mié., 19 sept. 2018 a las 12:39, Owen Leonard
>> (mailto:oleon...@myacpl.org>>) escribió:
>>
>> > > Bit late in the project to make this change imo? But yes, our
>> > > interpretation is quite different ;)
>> > But it's never too late to make a positive change, right ? :)
>>
>> I agree that it's not too late to make useful changes to our
>> workflow.
>> There was a time when we didn't even sign off patches!
>>
>> I'm not concerned that we're using "signed off" in a way that is
>> nonstandard, but I am interested in adding better information
>> to our
>> patches if it's useful.
>>
>> It sounds to me like this is something which QA and/or release
>> managers should decide.
>>
>>  -- Owen
>>
>> -- 
>> Web Developer
>> Athens County Public Libraries
>> https://www.myacpl.org
>> ___
>> Koha-devel mailing list
>> Koha-devel@lists.koha-community.org
>> <mailto:Koha-devel@lists.koha-community.org>
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>>
>>
>>
>> -- 
>> Tomás Cohen Arazi
>> Theke Solutions (http://theke.io <http://theke.io/>)
>> ✆ +54 9351 3513384
>> GPG: B2F3C15F
>>
>>
>> ___
>> Koha-devel mailing list
>> Koha-devel@lists.koha-community.org
>> <mailto:Koha-devel@lists.koha-community.org>
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
> 
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> <mailto:Koha-devel@lists.koha-community.org>
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 
> 
> 
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 

-- 
Julian Maurice 
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] git trailers: should we use more of them ?

[Julian Maurice]

Le 19/09/2018 à 16:44, Marcel de Rooy a écrit :
>> Should we replace Signed-off-by by Tested-By (for testers) and Reviewed-By 
>>(for QA) ?
>> Should we use Signed-off-by as suggested in the git-commit manpage ?
> Bit late in the project to make this change imo? But yes, our
> interpretation is quite different ;)
But it's never too late to make a positive change, right ? :)

> If we should switch to Tested-by and Reviewed-by (note: lowercase by),
> we should better start at a version release?
Probably, this would make it easier to distinguish between the two
different meanings of Signed-off-by in the git history.
That means all 'Signed off' patches would have to be rewritten after
that release. A bit tedious but not impossible.

> If so, what about the Bugzilla status Signed off etc.
I hadn't thought of that. Can the status be renamed easily ? git-bz
would need to be updated as well (and maybe other tools ?).

-- 
Julian Maurice 
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] git trailers: should we use more of them ?

[Julian Maurice]

Hi all,

AFAIK in our commit messages we are using two different trailers:
- Signed-off-by tells who tested/reviewed the patch
- Sponsored-by tells who sponsored the patch

I recently stumbled upon the contribution guidelines for git [1] which
suggests to use Reported-by, Acked-by, Reviewed-by, Tested-by and others
(Thanks-to, Mentored-by, ...)

I think it can be good to credit people who reported bugs or helped in a
way other than signing off or writing patches (testers that find bug are
helpful but they're not always the signoffers).
Also, the distinction between Tested-By and Reviewed-By could help in
situations where we don't know for sure if a signoff is only a test or a
full QA review.

This guide (and the git-commit manpage [2]) also states that we're not
really using the Signed-off-by trailer as intended. In short, a
"signoff" means (for git developers) that the patch author agrees to
https://developercertificate.org/

I'd like to know what you think about this.
Should we use Reported-By ?
Should we replace Signed-off-by by Tested-By (for testers) and
Reviewed-By (for QA) ?
Should we use Signed-off-by as suggested in the git-commit manpage ?

Do you think it is not worth the effort or that a change would be bad in
some way ?

Thanks


[1] https://github.com/git/git/blob/master/Documentation/SubmittingPatches
[2] https://git-scm.com/docs/git-commit#git-commit--s

-- 
Julian Maurice 
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Turn Koha into a Mojolicious application

[Julian Maurice]

Vote has closed. Thanks to all the people who took the time to read the
proposal and add their remarks !

Here are the results:

Agree: 7
Abstain: 1
Disagree: 0
Block: 0

89% of members have stated their position (8/9)

Next step is to look at Bug 20582, test it, and discuss the implementation.
I don't expect any movement here until 18.05 release, but it would be
great to have it in master in early 18.11 development cycle.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20582

Le 15/05/2018 à 13:24, Julian Maurice a écrit :
> Hi,
> 
> Just a little reminder: the Framavox vote will close in 24 hours. Almost
> everyone agreed to the proposal. If you want to add your opinion, you
> can still do it. I can extend the deadline if necessary.
> 
> Le 16/04/2018 à 15:32, Julian Maurice a écrit :
>> Hi all,
>>
>> I've been playing with Mojolicious recently and I thought it would be
>> great if Koha was a Mojolicious application (like the REST API already
>> is). Some pros:
>> - Easier deployment
>> - Testable CGI scripts (Test::Mojo)
>> - All Mojolicious features (routing, commands, plugins, ...)
>> - Koha already uses Mojolicious, so there's no new dependency.
>>
>> I wrote a POC here :
>> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20582
>>
>> I'd like to gather opinions on it, and for that I want to try something new.
>> I created a "Koha" group on framavox.org, an instance of Loomio (a free
>> software designed to make decisions).
>> In this group there is a discussion named "Bug 20582 - Turn Koha into a
>> Mojolicious application" where you can add comments.
>> And in this discussion there is a proposal where you can vote (Agree,
>> Abstain, Disagree, Block) and add a reason for your vote
>>
>> Group link : https://framavox.org/g/iAKeRC8Q/koha
>> Discussion link :
>> https://framavox.org/d/tTGf0Bzd/bug-20582-turn-koha-into-a-mojolicious-application
>>
>> To keep things clean, please
>> - use the framavox group to discuss about the idea of turning Koha into
>> a Mojolicious app (not the implementation)
>> - use the bug report to discuss about the implementation
>> - reply to this mail for anything else (feedback about framavox.org for
>> instance)
>>
>> Thanks
>>
> 

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Turn Koha into a Mojolicious application

[Julian Maurice]

Hi,

Just a little reminder: the Framavox vote will close in 24 hours. Almost
everyone agreed to the proposal. If you want to add your opinion, you
can still do it. I can extend the deadline if necessary.

Le 16/04/2018 à 15:32, Julian Maurice a écrit :
> Hi all,
> 
> I've been playing with Mojolicious recently and I thought it would be
> great if Koha was a Mojolicious application (like the REST API already
> is). Some pros:
> - Easier deployment
> - Testable CGI scripts (Test::Mojo)
> - All Mojolicious features (routing, commands, plugins, ...)
> - Koha already uses Mojolicious, so there's no new dependency.
> 
> I wrote a POC here :
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20582
> 
> I'd like to gather opinions on it, and for that I want to try something new.
> I created a "Koha" group on framavox.org, an instance of Loomio (a free
> software designed to make decisions).
> In this group there is a discussion named "Bug 20582 - Turn Koha into a
> Mojolicious application" where you can add comments.
> And in this discussion there is a proposal where you can vote (Agree,
> Abstain, Disagree, Block) and add a reason for your vote
> 
> Group link : https://framavox.org/g/iAKeRC8Q/koha
> Discussion link :
> https://framavox.org/d/tTGf0Bzd/bug-20582-turn-koha-into-a-mojolicious-application
> 
> To keep things clean, please
> - use the framavox group to discuss about the idea of turning Koha into
> a Mojolicious app (not the implementation)
> - use the bug report to discuss about the implementation
> - reply to this mail for anything else (feedback about framavox.org for
> instance)
> 
> Thanks
> 

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Proposed change to standard page markup (Bug 20670)

[Julian Maurice]

Le 27/04/2018 à 15:17, Owen Leonard a écrit :
> If anyone has comments or concerns, or would like to kibitz class
> names, please feel free!

Instead of class names, why not use the "new" HTML 5 elements, like
, ,  and the others ?

https://www.w3schools.com/HTML/html5_new_elements.asp

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] Turn Koha into a Mojolicious application

[Julian Maurice]

Hi all,

I've been playing with Mojolicious recently and I thought it would be
great if Koha was a Mojolicious application (like the REST API already
is). Some pros:
- Easier deployment
- Testable CGI scripts (Test::Mojo)
- All Mojolicious features (routing, commands, plugins, ...)
- Koha already uses Mojolicious, so there's no new dependency.

I wrote a POC here :
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20582

I'd like to gather opinions on it, and for that I want to try something new.
I created a "Koha" group on framavox.org, an instance of Loomio (a free
software designed to make decisions).
In this group there is a discussion named "Bug 20582 - Turn Koha into a
Mojolicious application" where you can add comments.
And in this discussion there is a proposal where you can vote (Agree,
Abstain, Disagree, Block) and add a reason for your vote

Group link : https://framavox.org/g/iAKeRC8Q/koha
Discussion link :
https://framavox.org/d/tTGf0Bzd/bug-20582-turn-koha-into-a-mojolicious-application

To keep things clean, please
- use the framavox group to discuss about the idea of turning Koha into
a Mojolicious app (not the implementation)
- use the bug report to discuss about the implementation
- reply to this mail for anything else (feedback about framavox.org for
instance)

Thanks

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Koha Core anyone?

[Julian Maurice]

t; parts missing. So it can be done.
> 
> But we'd love to hear second opinions from the community! We know the fear 
> for breaking changes, but
> its neither scary or complicated to implement!
> 
> Benjamin Rokseth
> Oslo Public Library
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] REST API authentication for external clients

[Julian Maurice]

I think a machine-to-machine authentication is what fits better for
Koha-Coral interface, but anything that doesn't require end-user
interaction would be good.

I guess I'll have to do some reading about OAuth :)

Thanks.

Le 27/02/2018 à 23:21, David Cook a écrit :
> Julian, could you say more about how you want to authenticate with Koha?
> 
>  
> 
> I’ve struggled in the past using OAuth2 for machine-to-machine
> authorization… although that Auth0 link that Tomas provided seems to
> suggest it is possible. Spotify uses OAuth2 for its REST API, and I had
> to do a bit of a workaround to get it working for machine-to-machine
> auth, but maybe that was an issue with their OAuth2 server or my lack of
> knowledge at the time.
> 
>  
> 
> I’m guessing you might want to look at
> https://auth0.com/docs/api-auth/grant/client-credentials, although it
> depends on whether you want the end user to access their account in Koha
> interactively or if you’re just looking for a way of authenticating with
> Koha on the backend I think.
> 
>  
> 
> I hadn’t heard of this flow before so I think I’ll have to look at it
> again when I one day have time for hobbies…
> 
>  
> 
> David Cook
> 
> Systems Librarian
> 
> Prosentient Systems
> 
> 72/330 Wattle St
> 
> Ultimo, NSW 2007
> 
> Australia
> 
>  
> 
> Office: 02 9212 0899
> 
> Direct: 02 8005 0595
> 
>  
> 
> *From:*koha-devel-boun...@lists.koha-community.org
> [mailto:koha-devel-boun...@lists.koha-community.org] *On Behalf Of
> *Tomas Cohen Arazi
> *Sent:* Wednesday, 28 February 2018 2:15 AM
> *To:* Julian Maurice <julian.maur...@biblibre.com>
> *Cc:* koha-devel@lists.koha-community.org
> *Subject:* Re: [Koha-devel] REST API authentication for external clients
> 
>  
> 
> Hi Julian, we need to implement an OAuth2 server inside Koha, using
> Mojolicious::Plugin::OAuth2::Server [1]. I've worked on an endpoint for
> authenticating the API against a generic OAuth2 server (as a way to be
> able to test it :-D). I will file a bug very soon for that. My idea was
> then to implement the server...
> 
>  
> 
> OAuth2 proposes several authorization flows, and the plugin (actually
> the server library) implements all of them. [2]
> 
>  
> 
> Hope it helps. I haven't managed to have the time to do it!
> 
>  
> 
> [1] https://metacpan.org/pod/Mojolicious::Plugin::OAuth2::Server
> 
> [2] https://auth0.com/docs/api-auth/which-oauth-flow-to-use
> 
>  
> 
>  
> 
> El mar., 27 feb. 2018 a las 12:04, Julian Maurice
> (<julian.maur...@biblibre.com <mailto:julian.maur...@biblibre.com>>)
> escribió:
> 
> Hi all,
> 
> As you may know [1], BibLibre is working on an interface between Koha
> and Coral. To achieve that, Coral uses the Koha REST API. But we are
> facing a problem that is becoming really blocking : the lack of a proper
> authentication system for the REST API.
> 
> At the moment, the only way to authenticate to the API is based on
> cookies. It works well for client-side javascript inside Koha, but it's
> not really usable by external clients.
> 
> Is there someone here who use this API outside of Koha ?
> If so, how do you authenticate to it ?
> 
> I think we really need an authentication mechanism other than cookies,
> so people can actually start using the API.
> 
> There is bug 13920 [2] that hasn't moved since 8 months. I remember that
> some people disagreed with this patchset because it is crafting a custom
> authentication system instead of using some "standard" one (I remember
>     OAuth was mentioned).
> Do you know of any "standard" auth system that we can implement, or
> existing Perl libraries we can use ?
> 
> 
> [1]:
> 
> http://lists.koha-community.org/pipermail/koha-devel/2017-January/043430.html
> [2]: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13920
> 
> --
> Julian Maurice <julian.maur...@biblibre.com
> <mailto:julian.maur...@biblibre.com>>
> BibLibre
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> <mailto:Koha-devel@lists.koha-community.org>
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 
> -- 
> 
> Tomás Cohen Arazi
> 
> Theke Solutions (https://theke.io <http://theke.io/>)
> ✆+54 9351 3513384
> GPG: B2F3C15F
> 

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] REST API authentication for external clients

[Julian Maurice]

Hi all,

As you may know [1], BibLibre is working on an interface between Koha
and Coral. To achieve that, Coral uses the Koha REST API. But we are
facing a problem that is becoming really blocking : the lack of a proper
authentication system for the REST API.

At the moment, the only way to authenticate to the API is based on
cookies. It works well for client-side javascript inside Koha, but it's
not really usable by external clients.

Is there someone here who use this API outside of Koha ?
If so, how do you authenticate to it ?

I think we really need an authentication mechanism other than cookies,
so people can actually start using the API.

There is bug 13920 [2] that hasn't moved since 8 months. I remember that
some people disagreed with this patchset because it is crafting a custom
authentication system instead of using some "standard" one (I remember
OAuth was mentioned).
Do you know of any "standard" auth system that we can implement, or
existing Perl libraries we can use ?


[1]:
http://lists.koha-community.org/pipermail/koha-devel/2017-January/043430.html
[2]: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13920

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] Length of email columns

[Julian Maurice]

Hi,

In the database schema, we use different data types to store email
adresses. Some are TEXT, some are MEDIUMTEXT, and there is
aqcontacts.email which is a VARCHAR(100).

According to https://stackoverflow.com/a/574698 the maximum length of an
email address is 254 characters, so VARCHAR(255) should be enough.
Do you know if there is any reason why we use mostly TEXT and MEDIUMTEXT
for these columns ?

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Plack only

[Julian Maurice]

Are they really in sync ? They look very different (I cannot use the
rest api with misc/plack/koha.psgi for instance).

IMO a good starting point would be to move debian/templates/plack.psgi
outside of debian/ and make it the .psgi reference file for all types of
install (and remove misc/plack in the process).
Any thoughts ?

Le 07/02/2018 à 13:37, Tomas Cohen Arazi a écrit :
> Good point, Julian. You are right.
> 
> Basically, we ship misc/plack/* which we keep in sync with
> debian/templates/plack.psgi.
> 
> I would love to spend some time de-debianizing hte multi-tenant
> management tools, but its been hard to find sponsorship or time for it.
> Most people are comfortable with Debian it seems.
> 
> Regards
> 
> El mié., 7 feb. 2018 a las 9:26, Julian Maurice
> (<julian.maur...@biblibre.com <mailto:julian.maur...@biblibre.com>>)
> escribió:
> 
> What about people that do not use Debian ? It seems that there is no
> "standard" way to use Plack outside of the Debian world, and it looks
> like 90% of https://wiki.koha-community.org/wiki/Plack is outdated.
> If we abandon CGI support, I think we should first provide a clear setup
> documentation. I would happily rewrite the wiki page, but I'm not sure
> of what to write (how to setup Plack on dev install for instance, or
> 'standard' install without debian packages).
> Or maybe I'm missing some important up-to-date documentation about
> Plack ?
> 
> (somewhat) related bug:
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18377
> 
> Le 06/02/2018 à 19:50, Tomas Cohen Arazi a écrit :
> > For running in Plack-mode, people needs to:
> >
> > sudo koha-plack --enable 
> > sudo koha-plack --start 
> > sudo systemctl restart apache2
> >
> > after creating the .
> >
> > What I meant is that we should have people avoid the need for those
> > commands. And people with specific needs that require non-Plack setups
> > can do it.
> >
> > I started thinking of this in the context of bug 20134 [1] BUT also in
> > the context of bugs 18315 [2] and 7174 [3].
> >
> > Both of the latter bugs propose interesting ways of refactoring
> > authentication, and I'm sure abandoning CGI-mode could help
> simplify the
> > process.
> >
> > [1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20134
> > [2] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18315
> > [3] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7174
> >
> > El mar., 6 feb. 2018 a las 11:00, Julian Maurice
> > (<julian.maur...@biblibre.com <mailto:julian.maur...@biblibre.com>
> <mailto:julian.maur...@biblibre.com
> <mailto:julian.maur...@biblibre.com>>>)
> > escribió:
> >
> >     What does that mean to "make Plack the default" exactly ?
> >
> >     Le 06/02/2018 à 14:31, Tomas Cohen Arazi a écrit :
> >     > I would like to know if you think there's any reason to keep
> the CGI
> >     > mode as default in Koha deployments. I think we should make
> Plack the
> >     > default. There are some issues, tough.
> >     >
> >     > But if we set that goal, we could focus on fixing them.
> >     >
> >     > What do you think?
> >     > --
> >     > Tomás Cohen Arazi
> >     > Theke Solutions (https://theke.io <http://theke.io/>)
> >     > ✆ +54 9351 3513384 <tel:+54%209%20351%20351-3384>
> <tel:+54%209%20351%20351-3384>
> >     > GPG: B2F3C15F
> >     >
> >     >
> >     > ___
> >     > Koha-devel mailing list
> >     > Koha-devel@lists.koha-community.org
> <mailto:Koha-devel@lists.koha-community.org>
> >     <mailto:Koha-devel@lists.koha-community.org
> <mailto:Koha-devel@lists.koha-community.org>>
> >     >
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> >     > website : http://www.koha-community.org/
> >     > git : http://git.koha-community.org/
> >     > bugs : http://bugs.koha-community.org/
> >     >
> >
> >     --
> >     Julian Maurice <julian.maur...@biblibre.com
> <mailto:julian.maur...@biblibre.com>
> >     <mailto:julian.maur...@biblibre.com
> <mailto:julian.maur...@bi

Re: [Koha-devel] Plack only

[Julian Maurice]

What about people that do not use Debian ? It seems that there is no
"standard" way to use Plack outside of the Debian world, and it looks
like 90% of https://wiki.koha-community.org/wiki/Plack is outdated.
If we abandon CGI support, I think we should first provide a clear setup
documentation. I would happily rewrite the wiki page, but I'm not sure
of what to write (how to setup Plack on dev install for instance, or
'standard' install without debian packages).
Or maybe I'm missing some important up-to-date documentation about Plack ?

(somewhat) related bug:
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18377

Le 06/02/2018 à 19:50, Tomas Cohen Arazi a écrit :
> For running in Plack-mode, people needs to:
> 
> sudo koha-plack --enable 
> sudo koha-plack --start 
> sudo systemctl restart apache2
> 
> after creating the .
> 
> What I meant is that we should have people avoid the need for those
> commands. And people with specific needs that require non-Plack setups
> can do it.
> 
> I started thinking of this in the context of bug 20134 [1] BUT also in
> the context of bugs 18315 [2] and 7174 [3].
> 
> Both of the latter bugs propose interesting ways of refactoring
> authentication, and I'm sure abandoning CGI-mode could help simplify the
> process.
> 
> [1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20134
> [2] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18315
> [3] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7174
> 
> El mar., 6 feb. 2018 a las 11:00, Julian Maurice
> (<julian.maur...@biblibre.com <mailto:julian.maur...@biblibre.com>>)
> escribió:
> 
> What does that mean to "make Plack the default" exactly ?
> 
> Le 06/02/2018 à 14:31, Tomas Cohen Arazi a écrit :
> > I would like to know if you think there's any reason to keep the CGI
> > mode as default in Koha deployments. I think we should make Plack the
> > default. There are some issues, tough.
> >
> > But if we set that goal, we could focus on fixing them.
> >
> > What do you think?
> > --
> > Tomás Cohen Arazi
> > Theke Solutions (https://theke.io <http://theke.io/>)
> > ✆ +54 9351 3513384 <tel:+54%209%20351%20351-3384>
> > GPG: B2F3C15F
> >
> >
> > ___
> > Koha-devel mailing list
> > Koha-devel@lists.koha-community.org
> <mailto:Koha-devel@lists.koha-community.org>
> > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> > website : http://www.koha-community.org/
> > git : http://git.koha-community.org/
> > bugs : http://bugs.koha-community.org/
> >
> 
> --
> Julian Maurice <julian.maur...@biblibre.com
> <mailto:julian.maur...@biblibre.com>>
> BibLibre
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> <mailto:Koha-devel@lists.koha-community.org>
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 
> -- 
> Tomás Cohen Arazi
> Theke Solutions (https://theke.io <http://theke.io/>)
> ✆ +54 9351 3513384
> GPG: B2F3C15F
> 
> 
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Plack only

[Julian Maurice]

What does that mean to "make Plack the default" exactly ?

Le 06/02/2018 à 14:31, Tomas Cohen Arazi a écrit :
> I would like to know if you think there's any reason to keep the CGI
> mode as default in Koha deployments. I think we should make Plack the
> default. There are some issues, tough.
> 
> But if we set that goal, we could focus on fixing them.
> 
> What do you think?
> -- 
> Tomás Cohen Arazi
> Theke Solutions (https://theke.io <http://theke.io/>)
> ✆ +54 9351 3513384
> GPG: B2F3C15F
> 
> 
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] git-bz: avoid storing unencrypted passwords in gitconfig

[Julian Maurice]

Hi,

I added a small example in the wiki that uses the 'cache' helper. If
someone is using another helper, it would be good to add it too.

Le 03/02/2018 à 09:20, Katrin Fischer a écrit :
> Hi all,
> 
> could/should we add this to the wiki?
> https://wiki.koha-community.org/wiki/Git_bz_configuration
> 
> And maybe kohadevbox?
> 
> Katrin
> 
> On 17.01.2018 21:30, Liz Rea wrote:
>> Deep approval, nice!
>>
>> Liz
>>
>>
>> On 17/01/18 23:14, Julian Maurice wrote:
>>> Hi all,
>>>
>>> I recently shared an LXD container containing my Koha dev environment,
>>> and of course I forgot to remove my Bugzilla credentials from the git
>>> config...
>>> I immediately changed it, but for that not to happen again I searched
>>> for a way to not have to store unencrypted passwords for git-bz.
>>>
>>> The result is here https://github.com/jajm/git-bz/tree/git-credential
>>>
>>> It uses git-credential, so you can theoretically use any password
>>> manager you want, as long as you can write a git-credential helper for
>>> it (I use the builtin 'cache' helper, which stores passwords in memory)
>>>
>>> I thought it might interest some people here.
>>>
>>> For more information, see the commit message at
>>> https://github.com/jajm/git-bz/commit/efb06d8fe3033a83772d0294ab5f67c7f51eaf57
>>>
> 
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] State of HTTP::OAI versions

[Julian Maurice]

You opened one ;)

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17704

Le 05/02/2018 à 12:01, Fridolin SOMERS a écrit :
> Hi,
> 
> Indeed,
> Is there a bugzilla number already ?
> 
> Le 01/02/2018 à 16:02, Jonathan Druart a écrit :
>>> It has been removed from HTTP::OAI::Response 4.03
>> This is wrong, the method still exist.
>> The change is that caused by (lib/HTTP/OAI/GetRecord.pm):
>> -@ISA = qw( HTTP::OAI::Response );
>> +@ISA = qw( HTTP::OAI::ListRecords );
>>
>> And there is no ->xslt in HTTP::OAI::ListRecords.
>> Sounds like we will need someone to have a complete look at 4.06 to adapt
>> our Koha::OAI modules.
>>
>>
>> On Thu, 1 Feb 2018 at 11:35 Jonathan Druart <
>> jonathan.dru...@bugs.koha-community.org> wrote:
>>
>>> Hi,
>>>
>>> Quick tests on master, hitting
>>> /cgi-bin/koha/
>>> oai.pl?verb=GetRecord=KOHA-OAI-TEST:1=marcxml
>>>
>>> 3.27 => OK
>>> 3.28 => OK
>>>
>>> 4.02 => KO cannot install via cpan
>>> make: *** No rule to make target 'bin/oai_pmh.pl', needed by 'blib/script/
>>> oai_pmh.pl'.  Stop.
>>>
>>> 4.03 => KO
>>> Can't call method "start_element" on an undefined value at
>>> /root/.cpanm/work/1517493937.13902/HTTP-OAI-4.03/blib/lib/HTTP/OAI/Verb.pm
>>> line 53.
>>> with --force:
>>> Can't locate object method "xslt" via package "HTTP::OAI::GetRecord" at
>>> /home/vagrant/kohaclone/Koha/OAI/Server/Repository.pm line 147.
>>>
>>> 4.04 to 4.06 => KO
>>> Can't locate object method "xslt" via package "HTTP::OAI::GetRecord" at
>>> /home/vagrant/kohaclone/Koha/OAI/Server/Repository.pm line 147.
>>>
>>> We use this xslt method since bug 15527 (OAI-PMH should have a stylesheet
>>> to aid usability).
>>> It has been removed from HTTP::OAI::Response 4.03
>>>
>>> If I comment the line in our codebase ($response->xslt(
>>> "/opac-tmpl/xslt/OAI.xslt" ); in Koha::OAI::Server::Repository->new), with
>>> 4.06 I get:
>>> Can't call method "start_element" on an undefined value at
>>> /usr/local/share/perl/5.20.2/HTTP/OAI/Verb.pm line 55.
>>>
>>> Next?
>>> I do not know :)
>>>
>>> Cheers,
>>> Jonathan
>>>
>>
>>
>>
>> ___
>> Koha-devel mailing list
>> Koha-devel@lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>>
> 

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Gitweb + Github?

[Julian Maurice]

I believe Github can detect if a pull request was merged, whether you
merge manually or use the web UI.
(By the way, to checkout pull request locally, see
https://gist.github.com/piscisaureus/3342247)

Anyway, I think it's better to have a single entry point for bugs,
patches, etc.

Le 05/02/2018 à 00:42, David Cook a écrit :
> Actually, upon further review, maybe they actually applied the changes
> manually and then merged the pull request just for Github record keeping.
> 
>  
> 
> It looks like the actual fix happened with
> https://git-wip-us.apache.org/repos/asf?p=jena.git;a=commit;h=db4a6205ebf045a866bfad4c4751a3372c34af24
> and the “merge” was a few days later with
> https://git-wip-us.apache.org/repos/asf?p=jena.git;a=commit;h=466f16558b9cd1a7a930fbb5e2844610ee8fb373
> 
>  
> 
> It looks like the Git maintainer is the same person posting to Github
> anyway, so… I don’t really know what’s going on there after all
> 
>  
> 
> David Cook
> 
> Systems Librarian
> 
> Prosentient Systems
> 
> 72/330 Wattle St
> 
> Ultimo, NSW 2007
> 
> Australia
> 
>  
> 
> Office: 02 9212 0899
> 
> Direct: 02 8005 0595
> 
>  
> 
> *From:*koha-devel-boun...@lists.koha-community.org
> [mailto:koha-devel-boun...@lists.koha-community.org] *On Behalf Of
> *David Cook
> *Sent:* Monday, 5 February 2018 10:36 AM
> *To:* 'koha-devel' <koha-devel@lists.koha-community.org>
> *Subject:* [Koha-devel] Gitweb + Github?
> 
>  
> 
> Hi y’all,
> 
>  
> 
> I know we’ve had a Gitweb vs Github thing going for years where GIthub
> is just a mirror.
> 
> But I saw something interesting today on Apache Jena’s Gitweb where it
> seems that they’d merged commits from Github into their master repo.
> 
>  
> 
> You can see it at https://git-wip-us.apache.org/repos/asf?p=jena.git and
> specifically with
> https://git-wip-us.apache.org/repos/asf?p=jena.git;a=commit;h=466f16558b9cd1a7a930fbb5e2844610ee8fb373.
> 
> 
>  
> 
> I guess it doesn’t mess with the mirroring because they’re not merging
> into the Github repositories. Rather, they’re merging in from pull
> requests, which appear to just be a different type of git ref.
> 
>  
> 
> I suppose that doesn’t help in terms of tracking things through
> Bugzilla… but I thought it was interesting nonetheless and thus worth
> sharing.
> 
>  
> 
> David Cook
> 
> Systems Librarian
> 
> Prosentient Systems
> 
> 72/330 Wattle St
> 
> Ultimo, NSW 2007
> 
> Australia
> 
>  
> 
> Office: 02 9212 0899
> 
> Direct: 02 8005 0595
> 
>  
> 
> 
> 
> ___________
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Debian 9 support

[Julian Maurice]

Hi,

I understand that you propose to package the older version of HTTP::OAI
(3.27 or 3.28), but wouldn't it be upgraded automatically to the most
recent version ?

From what I read, HTTP::OAI 4.03 is broken. Did anyone has tried the
latest release (4.06) ?

Le 29/01/2018 à 15:32, Tomas Cohen Arazi a écrit :
> Hi everyone, I wanted to highlight that Debian 9 is more used nowadays
> for Koha deployments, and we need to figure what to do with HTTP::OAI,
> which is causing constant complaints because Koha is broken with Debian
> 9's (and Ubuntu 16.04's).
> 
> I propose we package it in our repo, or just put the code on our source
> tree if packaging it becomes problematic for whatever reason.
> 
> Ideas?
> -- 
> Tomás Cohen Arazi
> Theke Solutions (https://theke.io <http://theke.io/>)
> ✆ +54 9351 3513384
> GPG: B2F3C15F
> 
> 
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Centralize and move to gitlab

[Julian Maurice]

+1

Other repositories that could benefit from moving to gitlab:
- git-bz
- koct-webext (which is currently hosted at git.biblibre.com)

Le 23/01/2018 à 20:46, Jonathan Druart a écrit :
> Hi devs,
> 
> (Spoiler: I am not talking about a move from bugzilla to gitlab for the
> Koha git repo)
> 
> Just a quick comment: gitlab has the ability to move projects with all
> the issues.
> 
> From the export page of a project, they say:
> """
> The following items will be exported:
> Project and wiki repositories
> Project uploads
> Project configuration including web hooks and services
> Issues with comments, merge requests with diffs and comments, labels,
> milestones, snippets, and other project entities
> """
> 
> So that will be easy to move (already discussed with Chris, will do in May)
> * koha-community-devs-users/kohadocs to koha-community/kohadocs
> * https://gitlab.com/koha-dashboard/koha-dashboard to
> koha-community/koha-dashboard
> 
> And the ones from github too:
> * joubu/koha-misc4dev to koha-community/koha-misc4dev
> * Koha-Community/qa-test-tools to koha-community/qa-test-tools
> 
> Then, maybe:
> koha-testing-docker
> koha-release-notes
> kohadevbox
> koha-howto
> 
> The idea is to centralize our things in one place, ease the PRs and the
> ability to clone/fork keeping the visibility on what is the reference
> (account 'koha-community'). I would also like to generate a CI
> configuration for some of them.
> CI file for Koha:
> https://tree.taiga.io/project/joubu-koha-rm-1711/us/146 (I am going to
> submit that on bugzilla soon)
> CI file for the manual:
> https://gitlab.com/koha-community-devs-users/kohadocs/blob/master/.gitlab-ci.yml
> 
> Any pros/cons?
> 
> Cheers,
> Jonathan
> 
> (No troll please)
> 
> 
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] git-bz: avoid storing unencrypted passwords in gitconfig

[Julian Maurice]

+1 for using master branch instead of fishsoup (or at least make
fishsoup the default branch so we don't have to specify branch when cloning)

I see that you did retrieve the "git-credential" commit on fishsoup
branch (did you check that it continues to work for those that have
password in their gitconfig ? I did, but another check would be good),
but not the apply_on_cascade branch, why ?

Also, I have a suggestion for git-bz for which I would like to hear
other people opinion:
I think we should use Github/Gitlab/... (whatever platform that makes
easy for people to fork and create pull requests) and give push
permission to anyone interested in reviewing pull requests. That
suggestion also applies to our QA tools. I think that would ease and
encourage improvements. Any thoughts ?

Le 18/01/2018 à 19:38, Jonathan Druart a écrit :
> Very long standing issues, good to see it fixed :)
> I have picked the commit for the apply_on_cascade branch of my github repo.
> Maybe we should make it (apply on cascade + use-git-credential) the
> default and push it to the community/master(or fishsoup) branch.
> 
> By the way the fishsoup repo is 37 commits ahead from us :-/
> http://git.fishsoup.net/cgit/git-bz/
> 
> On Wed, 17 Jan 2018 at 07:14 Julian Maurice <julian.maur...@biblibre.com
> <mailto:julian.maur...@biblibre.com>> wrote:
> 
> Hi all,
> 
> I recently shared an LXD container containing my Koha dev environment,
> and of course I forgot to remove my Bugzilla credentials from the git
> config...
> I immediately changed it, but for that not to happen again I searched
> for a way to not have to store unencrypted passwords for git-bz.
> 
> The result is here https://github.com/jajm/git-bz/tree/git-credential
> 
> It uses git-credential, so you can theoretically use any password
> manager you want, as long as you can write a git-credential helper for
> it (I use the builtin 'cache' helper, which stores passwords in memory)
> 
> I thought it might interest some people here.
> 
> For more information, see the commit message at
>     
> https://github.com/jajm/git-bz/commit/efb06d8fe3033a83772d0294ab5f67c7f51eaf57
> 
> --
> Julian Maurice <julian.maur...@biblibre.com
> <mailto:julian.maur...@biblibre.com>>
> BibLibre
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> <mailto:Koha-devel@lists.koha-community.org>
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] git-bz: avoid storing unencrypted passwords in gitconfig

[Julian Maurice]

I tried libsecret with gnome-keyring, it worked the first time, but not
the other ones infortunately...
I get this error message:
https://stackoverflow.com/questions/36585496/error-when-using-git-credential-helper-with-gnome-keyring-as-sudo#comment70025417_40312117
If you know how to fix it, please share! :)

Le 18/01/2018 à 02:14, David Cook a écrit :
> This issue has annoyed me for years, so this sounds pretty cool! 
> 
> I don't love the "cache" and "store" options... but it looks like there
> might be an alternative using libsecret or the gnome keyring. These
> alternatives can be found in separate packages or built from source it
> seems.
> 
> On OpenSUSE, I just installed " git-credential-gnome-keyring". On Arch, they
> use libsecret:
> https://wiki.archlinux.org/index.php/GNOME/Keyring#Git_integration. 
> 
> It looks like the gnome keyring one is deprecated
> (https://stackoverflow.com/questions/36585496/error-when-using-git-credentia
> l-helper-with-gnome-keyring-as-sudo), so libsecret is probably the way to
> go. 
> 
> I've tried using /usr/lib/git/git-credential-gnome-keyring, but it doesn't
> seem to be working. Admittedly I'm just using a SSH session rather than a
> GUI session. I launched DBUS so I don't get errors but it's not saving
> credentials using "git credential approve". The "cache" option worked well
> though. 
> 
> 
> David Cook
> Systems Librarian
> Prosentient Systems
> 72/330 Wattle St
> Ultimo, NSW 2007
> Australia
> 
> Office: 02 9212 0899
> Direct: 02 8005 0595
> 
> 
> -Original Message-
> From: koha-devel-boun...@lists.koha-community.org
> [mailto:koha-devel-boun...@lists.koha-community.org] On Behalf Of Julian
> Maurice
> Sent: Wednesday, 17 January 2018 9:14 PM
> To: koha-devel@lists.koha-community.org
> Subject: [Koha-devel] git-bz: avoid storing unencrypted passwords in
> gitconfig
> 
> Hi all,
> 
> I recently shared an LXD container containing my Koha dev environment, and
> of course I forgot to remove my Bugzilla credentials from the git config...
> I immediately changed it, but for that not to happen again I searched for a
> way to not have to store unencrypted passwords for git-bz.
> 
> The result is here https://github.com/jajm/git-bz/tree/git-credential
> 
> It uses git-credential, so you can theoretically use any password manager
> you want, as long as you can write a git-credential helper for it (I use the
> builtin 'cache' helper, which stores passwords in memory)
> 
> I thought it might interest some people here.
> 
> For more information, see the commit message at
> https://github.com/jajm/git-bz/commit/efb06d8fe3033a83772d0294ab5f67c7f51eaf
> 57
> 
> --
> Julian Maurice <julian.maur...@biblibre.com> BibLibre
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/ git :
> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
> 
> 

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] git-bz: avoid storing unencrypted passwords in gitconfig

[Julian Maurice]

Hi all,

I recently shared an LXD container containing my Koha dev environment,
and of course I forgot to remove my Bugzilla credentials from the git
config...
I immediately changed it, but for that not to happen again I searched
for a way to not have to store unencrypted passwords for git-bz.

The result is here https://github.com/jajm/git-bz/tree/git-credential

It uses git-credential, so you can theoretically use any password
manager you want, as long as you can write a git-credential helper for
it (I use the builtin 'cache' helper, which stores passwords in memory)

I thought it might interest some people here.

For more information, see the commit message at
https://github.com/jajm/git-bz/commit/efb06d8fe3033a83772d0294ab5f67c7f51eaf57

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Bug 18539 - Forbid Koha::Objects->find calls in list context

[Julian Maurice]

Probably, but that's not my point.

I understand why the previous code needed to be fixed, which is to avoid
that

{ a => Koha::Patrons->find("foo"), b => "bar" }

would result in { a => "b", "bar" => undef }

My question is: why the solution to this problem was to forbid calls in
list context while we could simply return an explicit undef?
It forces us to write 'scalar' in front of a call that should always
return a single value, and in my opinion it's a "code smell"

Le 13/12/2017 à 15:29, Marcel de Rooy a écrit :
> i forgot to add scalar in the second..
> 
> probably you should
> 
> if( $a = xxx->find )
> 
>    push @b, $a
> 
> 
> 
> *Van:* Julian Maurice <julian.maur...@biblibre.com>
> *Verzonden:* woensdag 13 december 2017 15:20:34
> *Aan:* Marcel de Rooy
> *Onderwerp:* Re: [Koha-devel] Bug 18539 - Forbid Koha::Objects->find
> calls in list context
>  
> This particular line will work (only the first, in the second, find is
> still called in list context), but @a would contain one element (undef)
> and the example code given by Jonathan will also fail, whether we call
> find in list context or not.
> 
> Le 13/12/2017 à 15:12, Marcel de Rooy a écrit :
>> Are you sure ?
>> 
>> push @a, scalar Koha..->find
>> 
>> or @a = ( ...->find )
>> 
>> 
>> should work imo
>> 
>> 
>> *Van:* koha-devel-boun...@lists.koha-community.org
>> <koha-devel-boun...@lists.koha-community.org> namens Julian Maurice
>> <julian.maur...@biblibre.com>
>> *Verzonden:* woensdag 13 december 2017 15:07:11
>> *Aan:* Jonathan Druart
>> *CC:* koha-devel@lists.koha-community.org
>> *Onderwerp:* Re: [Koha-devel] Bug 18539 - Forbid Koha::Objects->find
>> calls in list context
>>  
>> Ok, but the proposed fix doesn't fix this code:
>> 
>> @a = scalar Koha::Patrons->find('foo');
>> if (@a) { # still equals to 1
>>   say $a[0]->borrowernumber; # still BOOM
>> }
>> 
>> And yes, that was the link ;)
>> 
>> Le 13/12/2017 à 14:58, Jonathan Druart a écrit :
>>> Hi Julian,
>>> 
>>> 
>>>> @a = Koha::Patrons->find('foo'); # would result in @a = (undef)
>>> 
>>> And that leads to issues:
>>> if ( @a ) { # = 1
>>>   say $a[0]->borrowernumber; # BOOM
>>> }
>>> 
>>> See also https://perlmaven.com/how-to-return-undef-from-a-function (was
>>> it the link you were talking about?)
>>> 
>>> Cheers,
>>> Jonathan
>>> 
>>> On Wed, 13 Dec 2017 at 10:34 Julian Maurice <julian.maur...@biblibre.com
>>> <mailto:julian.maur...@biblibre.com>> wrote:
>>> 
>>> Hi developers,
>>> 
>>> I stumbled upon a line of code recently and I can't figure out why it
>>> has be done this way. I hope you can help me :)
>>> 
>>> The line in question is in Koha::Objects::find:
>>> 
>>>     croak 'Cannot use "->find" in list context' if wantarray;
>>> 
>>> I read the two bugs (18539 and 18179) and the link given by Jonathan but
>>> I still don't understand why the call in list context has been
>>> forbidden. Why not simply return undef (an explicit undef) when no
>>> records have be found ? It would work as expected in scalar and list
>>> contexts.
>>> 
>>> Here is a possible rewrite of 'find' to better explain what I mean:
>>> 
>>>     sub find {
>>>         my ( $self, @pars ) = @_;
>>> 
>>>         my $object = undef;
>>> 
>>>         @pars = grep { defined } @pars;
>>>         if (@pars) {
>>>             my $result = $self->_resultset()->find(@pars);
>>>             if ($result) {
>>>                 $object =
>>> $self->object_class()->_new_from_dbic($result);
>>>             }
>>>         }
>>> 
>>>         return $object;
>>>     }
>>> 
>>> @a = Koha::Patrons->find('foo'); # would result in @a = (undef)
>>> {a => K::P->find('foo'), b => 'bar'}; # would result in {a => undef, b
>>> => 'bar'}
>>> 
>>> Please tell me what you think.
>>> 
>>> --
>>> Julian Maurice <julian.ma

Re: [Koha-devel] Bug 18539 - Forbid Koha::Objects->find calls in list context

[Julian Maurice]

Ok, but the proposed fix doesn't fix this code:

@a = scalar Koha::Patrons->find('foo');
if (@a) { # still equals to 1
  say $a[0]->borrowernumber; # still BOOM
}

And yes, that was the link ;)

Le 13/12/2017 à 14:58, Jonathan Druart a écrit :
> Hi Julian,
> 
> 
>> @a = Koha::Patrons->find('foo'); # would result in @a = (undef)
> 
> And that leads to issues:
> if ( @a ) { # = 1
>   say $a[0]->borrowernumber; # BOOM
> }
> 
> See also https://perlmaven.com/how-to-return-undef-from-a-function (was
> it the link you were talking about?)
> 
> Cheers,
> Jonathan
> 
> On Wed, 13 Dec 2017 at 10:34 Julian Maurice <julian.maur...@biblibre.com
> <mailto:julian.maur...@biblibre.com>> wrote:
> 
> Hi developers,
> 
> I stumbled upon a line of code recently and I can't figure out why it
> has be done this way. I hope you can help me :)
> 
> The line in question is in Koha::Objects::find:
> 
>     croak 'Cannot use "->find" in list context' if wantarray;
> 
> I read the two bugs (18539 and 18179) and the link given by Jonathan but
> I still don't understand why the call in list context has been
> forbidden. Why not simply return undef (an explicit undef) when no
> records have be found ? It would work as expected in scalar and list
> contexts.
> 
> Here is a possible rewrite of 'find' to better explain what I mean:
> 
>     sub find {
>         my ( $self, @pars ) = @_;
> 
>         my $object = undef;
> 
>         @pars = grep { defined } @pars;
>         if (@pars) {
>             my $result = $self->_resultset()->find(@pars);
>             if ($result) {
>                 $object =
> $self->object_class()->_new_from_dbic($result);
>             }
>         }
> 
>         return $object;
>     }
> 
> @a = Koha::Patrons->find('foo'); # would result in @a = (undef)
> {a => K::P->find('foo'), b => 'bar'}; # would result in {a => undef, b
> => 'bar'}
> 
> Please tell me what you think.
> 
> --
> Julian Maurice <julian.maur...@biblibre.com
> <mailto:julian.maur...@biblibre.com>>
> BibLibre
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> <mailto:Koha-devel@lists.koha-community.org>
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Bug 18539 - Forbid Koha::Objects->find calls in list context

[Julian Maurice]

I know that find is supposed to retrieve only one result. That's why we
shouldn't have to care about the context, it's never ambiguous.
I should be allowed to write

push @patrons, Koha::Patrons->find($borrowernumber);

without specifying that I only want one record (using 'scalar')

Le 13/12/2017 à 14:50, Marcel de Rooy a écrit :
> Find is supposed for retrieving one result not multiple ones. Use search
> instead.
> 
> Using find in a list context is not correct.
> 
> 
> *Van:* koha-devel-boun...@lists.koha-community.org
> <koha-devel-boun...@lists.koha-community.org> namens Julian Maurice
> <julian.maur...@biblibre.com>
> *Verzonden:* woensdag 13 december 2017 14:34:07
> *Aan:* koha-devel@lists.koha-community.org
> *Onderwerp:* [Koha-devel] Bug 18539 - Forbid Koha::Objects->find calls
> in list context
>  
> Hi developers,
> 
> I stumbled upon a line of code recently and I can't figure out why it
> has be done this way. I hope you can help me :)
> 
> The line in question is in Koha::Objects::find:
> 
>     croak 'Cannot use "->find" in list context' if wantarray;
> 
> I read the two bugs (18539 and 18179) and the link given by Jonathan but
> I still don't understand why the call in list context has been
> forbidden. Why not simply return undef (an explicit undef) when no
> records have be found ? It would work as expected in scalar and list
> contexts.
> 
> Here is a possible rewrite of 'find' to better explain what I mean:
> 
>     sub find {
>     my ( $self, @pars ) = @_;
> 
>     my $object = undef;
> 
>     @pars = grep { defined } @pars;
>     if (@pars) {
>     my $result = $self->_resultset()->find(@pars);
>     if ($result) {
>     $object = $self->object_class()->_new_from_dbic($result);
>     }
>     }
> 
>     return $object;
>     }
> 
> @a = Koha::Patrons->find('foo'); # would result in @a = (undef)
> {a => K::P->find('foo'), b => 'bar'}; # would result in {a => undef, b
> => 'bar'}
> 
> Please tell me what you think.
> 
> -- 
> Julian Maurice <julian.maur...@biblibre.com>
> BibLibre
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] Bug 18539 - Forbid Koha::Objects->find calls in list context

[Julian Maurice]

Hi developers,

I stumbled upon a line of code recently and I can't figure out why it
has be done this way. I hope you can help me :)

The line in question is in Koha::Objects::find:

croak 'Cannot use "->find" in list context' if wantarray;

I read the two bugs (18539 and 18179) and the link given by Jonathan but
I still don't understand why the call in list context has been
forbidden. Why not simply return undef (an explicit undef) when no
records have be found ? It would work as expected in scalar and list
contexts.

Here is a possible rewrite of 'find' to better explain what I mean:

sub find {
my ( $self, @pars ) = @_;

my $object = undef;

@pars = grep { defined } @pars;
if (@pars) {
my $result = $self->_resultset()->find(@pars);
if ($result) {
$object = $self->object_class()->_new_from_dbic($result);
}
}

return $object;
}

@a = Koha::Patrons->find('foo'); # would result in @a = (undef)
{a => K::P->find('foo'), b => 'bar'}; # would result in {a => undef, b
=> 'bar'}

Please tell me what you think.

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Koha 3.22.21 release

[Julian Maurice]

Glad to read that :-)
Thanks

Le 22/05/2017 à 19:04, Tomas Cohen Arazi a écrit :
> Julian, 3.22 was pretty good :-D
> Well done!
> 
> El lun., 22 may. 2017 a las 13:17, Julian Maurice
> (<julian.maur...@biblibre.com <mailto:julian.maur...@biblibre.com>>)
> escribió:
> 
> The Koha community is proud to announce the release of Koha 3.22.21.
> 
> This is a maintenance release and contains several bugfixes.
> 
> The full release notes are available at
> https://koha-community.org/koha-3-22-21-release/
> 
> Please note that Koha version 3.22 won't be maintained anymore and this
> is the last 3.22 release. If you are still using it, you should consider
> upgrading to a more recent version.
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> <mailto:Koha-devel@lists.koha-community.org>
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 
> -- 
> Tomás Cohen Arazi
> Theke Solutions (https://theke.io <http://theke.io/>)
> ✆ +54 9351 3513384
> GPG: B2F3C15F

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] Koha 3.22.21 release

[Julian Maurice]

The Koha community is proud to announce the release of Koha 3.22.21.

This is a maintenance release and contains several bugfixes.

The full release notes are available at
https://koha-community.org/koha-3-22-21-release/

Please note that Koha version 3.22 won't be maintained anymore and this
is the last 3.22 release. If you are still using it, you should consider
upgrading to a more recent version.
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] [Koha] Koha 3.22.20 security release

[Julian Maurice]

The Koha community is proud to announce the release of Koha 3.22.20.

This is a security release and contains several bugfixes.
If you are running 3.22.x it is strongly recommended to upgrade.

The full release notes are available at
https://koha-community.org/koha-3-22-20-security-release/
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Plack and CGI : where to put initialization code ?

[Julian Maurice]

Le 10/04/2017 à 10:42, Francesco Rivetti a écrit :

On 10. april 2017 10:39, Julian Maurice wrote:

I need to execute code at the beginning of every request. For now it's
in a BEGIN block. It works well in CGI mode, but not at all with plack
(it's only executed once).
I tried moving the BEGIN block into a sub init(), calling this sub in
the BEGIN block and in the PSGI file (in CGI::new wrapper). It works but
it doesn't feel "right".


probably the best way in plack is to "enable" it in the build chain,
like it is happening with Koha::Middleware::SetEnv in plack.psgi

HTH

F


I haven't thought of that. I'll give it a try.
Thanks!

--
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] Plack and CGI : where to put initialization code ?

[Julian Maurice]

Hello developers,

I need to execute code at the beginning of every request. For now it's 
in a BEGIN block. It works well in CGI mode, but not at all with plack 
(it's only executed once).
I tried moving the BEGIN block into a sub init(), calling this sub in 
the BEGIN block and in the PSGI file (in CGI::new wrapper). It works but 
it doesn't feel "right".


Is there a common place to put this kind of code ?
Should I use the L1 cache (which is flushed at every request) to store 
some state (initialized or no) and call init() in every method of the 
module or something like that ?


--
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] [Koha] Koha 3.22.19 security release

[Julian Maurice]

The Koha community is proud to announce the release of Koha 3.22.19.

This is a security release and contains several bugfixes.
If you are running 3.22.x it is strongly recommended to upgrade.

The full release notes are available at
https://koha-community.org/koha-3-22-19-security-release/
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] CSRF token problem ?

[Julian Maurice]

Hi,

I think I found a problem with how we use CSRF tokens.
If a token is discovered by an attacker, and if the user leaves their 
session open, the attacker can use the token to impersonate the user on 
every CSRF-protected form during 8 hours (Koha::Token::CSRF_EXPIRY_HOURS).


Is this a known issue ?

Bug 18124 restricts token to a user's session. Maybe it would be good to 
restrict to a particular form too.
To go further, I think we should have a way to invalidate tokens after 
their use, so a token can never be used twice.


Any thoughts ?

--
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] To React or not to React

[Julian Maurice]

On 22/09/2016 14:56, Owen Leonard wrote:
> - How does using React affect translations?
> 
> My impression from looking at React examples online (and from Bug
> 17297) is that React JS very often includes HTML markup in a way which
> would be too cumbersome to manage with the way we handle
> internationalization in JavaScript at this time. The volume of strings
> which would have to be defined in the templates would be unmanageable.

I don't know React, but it looks like this particular problem can be
solved by bug 15395. It allows (among other things) strings defined in
.js files to be translatable.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15395

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] ILSDI - GetAvailability

[Julian Maurice]

Hello Arthur,

You're not doing anything wrong. The GetAvailability implementation in
Koha works only when id_type=item. And I believe the parameter
'return_type' is not used at all.

Please open a bug report on https://bugs.koha-community.org/

On 16/09/2016 10:45, SUZUKI Arthur wrote:
> Hello people,
> First of all I wishes everyone have spent a nice summer!
> 
> At my work we're trying to use ILSDI to get availability of all items 
> for a biblionumber.
> 
> Thanks to Julian we were able to use the GetAvailability method to get 
> availability for one item at a time.
> 
> https://catalogue.univ-lyon3.fr/cgi-bin/koha/ilsdi.pl?service=GetAvailability=510054_type=item
> 
> According to the documentation it is possible to query this script with 
> biblionumber rather than itemnumber to get availability of all items in 
> one shot.
> 
> https://catalogue.univ-lyon3.fr/cgi-bin/koha/ilsdi.pl?service=GetAvailability=334726_type=bib_type=item
> 
> The late query is then supposed to work but it doesn't.
> Am I doing something wrong?
> 
> Thanks in advance for your wisdom and enlightenment!
> Best regards,
> 
> Arthur Suzuki
> University Jean Moulin Lyon 3
> 


-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] 3 tiny but very useful things

[Julian Maurice]

Hi!

On 09/09/2016 11:03, Jonathan Druart wrote:
> Hi devs,
> 
> I have fixed 3 tiny things this morning:
> 
> 1/ Fold obsolete patches
> I have sent a SQL query to Chris to automatically add the obsolete tag
> to the obsolete comment. That will cause them to be collapsed by
> default (was already fixed previously by a greasemonkey script).

Will the query be run only once or periodically (ie. can i throw away
the greasemonkey script) ? The GM script is useful to hide comments
about obsolete patch for example (is that what you mean by "obsolete
comments" ?)

> 3/ The last, but not the least.
> Yesterday on #koha
> "oleonard wishes for git-bz auto-applying of dependent patches"
> Hum... not that hard finally, here it is:
> https://github.com/joubu/git-bz/tree/apply_on_cascade
> A good example to learn how it works:
>   git bz apply 17249
> Have fun :)
> Disclaimer: This has not been tested deeply (but should not make your
> computer burst into flames)

Great!
Does it handle cases where dependencies are referenced more than once ?
Example: bug 1 depends on bugs 2 and 3, but bug 3 also depends on bug 2.
It should apply 2 only once.
Little improvement suggestion: add a switch to enable/disable this
feature. Something like --follow-deps=always|interactive|never so it
could be used more easily in scripts.

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] (deleted)borrowers.updated_on nullable or not ?

[Julian Maurice]

On 05/09/2016 12:50, Julian Maurice wrote:
> Hi,
> 
> I noticed that (deleted)borrowers.updated_on (introduced by bug 10459)
> is defined as nullable in updatedatabase.pl but not nullable in
> kohastructure.sql and Koha::Schema.
> I started writing a patch to fix this in updatedatabase.pl but I'm not
> sure of what should be the correct definition.
> Any thoughts ?
> 

Same question for constraint on old_reserves.itemtype (SET NULL in
kohastructure.sql and Koha::Schema, CASCADE in updatedatabase.pl)

Also, virtualshelves.created_on is a DATETIME in updatedatabase.pl and
kohastructure.sql, but a TIMESTAMP in Koha::Schema (could be fixed by
just regenerating Koha::Schema)

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Release unification: Security fixes and releases

[Julian Maurice]

On 26/08/2016 17:41, Frédéric Demians wrote:
>> I propose to…
> 
>> - use the label "security release" in the release notes headline and
>> first paragraph (and Wordpress URL)
>> - mention number of security fixes seperately
>> - display them under the headline "Security bugs fixed" on top of
>> the list
> 
>> …whenever there are patches from "Koha security" in a release.
> 
> It seems that Julian do it this way with 3.20 branch.
> 
> For 16.05, I use a script which generates automatically release notes. This
> script doesn't distinguish "security" patches from others. The script could be
> modified of course. I'd be curious to know how Julian creates his release
> notes, automatically or by hand, or a mix.
> 
> Kind regards,
> 

I believe I use the same script as you, but I make some minor changes by
hand

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Time to think Plack?

[Julian Maurice]

Hi Tomas,

As I haven't worked much with Plack, I am not sure to understand what
you mean by "thinking of Koha as a Plack app". Do you mean rewrite Koha
so that Plack::App::CGIBin is not needed to make it work under Plack ?

How is it related to the API implementation with Mojolicious ?
I believe Mojolicious apps can be turned into Plack apps quite easily.
Are you suggesting we should extend the use of Mojolicious to all parts
of Koha ?

On 04/05/2016 14:39, Tomas Cohen Arazi wrote:
> Hi everyone, I just wanted to raise some questions, that might be worth
> thinking about at the KohaCon16 hackfest, or just here.
> 
> Koha has been a CGI app for ages. And we slowly made it work under Plack
> to gain performance. We did so, by running it inside a CGI emulation
> context (i.e. CGI::Emulate::PSGI [1]). We even wired all stuff so
> packages can take advantage of Plack out of the box (just not enabled by
> default, that'd be a next future step).
> 
> We then introduced a Mojolicious implementation of (a beggining of) a
> REST API.
> 
> Is it time to start thinking of Koha as a Plack app and focus on that?
> 
> 
> [1] Through Plack::App::CGIBin actually.
> 
> -- 
> Tomás Cohen Arazi
> Theke Solutions (http://theke.io <http://theke.io/>)
> ✆ +54 9351 3513384
> GPG: B2F3C15F
> 
> 
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 


-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Plan for upgrading jQuery in the staff client

[Julian Maurice]

jQuery 1.12 seems to be the last release of the 1.x branch.
What's next ? Should we upgrade to 2.x ? 3.x ?

I have a preference for the "upgrade all at once / fix as it breaks"
method. With the other method I think we will end up with several
versions of jQuery and doc-head-close-*
Moreover, the upgrade path from 1.7 to 1.12 seems not too hard,
according to https://jquery.com/upgrade-guide/1.9 and we can use the
jQuery Migrate plugin.

Le 07/04/2016 18:02, Owen Leonard a écrit :
>> I have filed a new bug with a plan for how to move forward on an
>> upgrade of jQuery in the staff client.
>>
>> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15883
> 
> This is stuck, so I need to ask for suggestions on how to proceed.
> Jonathan and I have two different proposals. Mine:
> 
> - Create a new include file which uses new version of jQuery and
> jQueryUI. Name that include file according to the version of jQuery it
> includes ("doc-head-close-jquery-1.12.0.inc").
> 
> - Gradually (page by page or in batches) submit patches which add use
> of the new include file while making any changes to the affected
> page(s) to update relevant JavaScript to work with the new versions.
> 
> Advantages to this method: Small manageable patches, nothing breaks
> without warning.
> Disadvantages to this method: We introduce duplicate versions of
> doc-head-close.inc which must be kept in sync. There could end up
> being many many patches.
> 
> Jonathan suggests that we update jQuery and jQueryUI without creating
> a new include file and fixing bugs as we find them.
> 
> Advantages to this method: One patch, and we don't have to deal with
> include file renaming.
> Disadvantages to this method: It is not known what pages will break
> because of the new versions of jQuery and jQueryUI.
> 
> Jonathan please correct me if I have mis-characterized your proposal.
> 
> What does everyone think? Should I bring this up for a vote at the
> next dev meeting?
> 
>   -- Owen
> 


-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Koha::Object validation ?

[Julian Maurice]

I was thinking about calling $self->before_save() in Koha::Object::store
and then define Koha::AuthorisedValues::before_save, but that's kind of
the same thing. I'll go with overwriting the store method, thanks ;)

Le 15/02/2016 16:22, Jonathan Druart a écrit :
> Hi Julian,
> 
> You want to overwrite the store method, that's it?
> You can have a look at Koha::VirtualShelf->store for an example.
> 
> Jonathan
> 
> 2016-02-15 14:20 GMT+00:00 Julian Maurice <julian.maur...@biblibre.com>:
>> Hi there,
>>
>> I'm currently working on some enhancements for authorised values (to
>> make it possible to have a hierarchy of values), so I'm using
>> Koha::AuthorisedValue which is a subclass of Koha::Object.
>>
>> I would like to add some sort of validation mechanism just before saving
>> the object into database.
>> Is there already someone who started to work (or started to think) on
>> something like that ?
>> Jonathan, maybe ?
>>
>> --
>> Julian Maurice <julian.maur...@biblibre.com>
>> BibLibre
>> ___
>> Koha-devel mailing list
>> Koha-devel@lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 


-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Country-specific forks?

[Julian Maurice]

Problems that quickly come to mind with this solution:
* It will prevent 2 different plugins to redefine the same subroutine
* If the subroutine "signature" change, the compatibility with existing
plugins will be broken


Le 11/02/2016 13:14, Jonathan Druart a écrit :
> A really easy solution to implement would be to watch a directory (say
> plugins) during the very end of the compilation time.
> Using something like Sub::Override
> (http://search.cpan.org/~ovid/Sub-Override-0.09/lib/Sub/Override.pm)
> would allow the plugin to redefine behaviors.
> 
> 2016-02-11 11:47 GMT+00:00 Kyle Hall <kyle.m.h...@gmail.com>:
>> Totally agree with this. All we need to do is imagine where we want Koha to
>> be pluggable! So far we have the ability create Report/Tool plugins,
>> arbitrary file to MARC conversion plugins, and I also have submitted a patch
>> to make EDIFACT pluggable ( once it gets it ). The first step is to know
>> what behavior needs to be modified, then make that behavior pluggable. It's
>> almost a chicken or the egg issue. I suppose what we need to do is watch for
>> new patches for very region specific features ( such as Norwegian patron DB
>> ) and suggest a path to plug-ability rather pushing the code itself into
>> Koha.
>>
>> Kyle
>>
>> http://www.kylehall.info
>> ByWater Solutions ( http://bywatersolutions.com )
>> Meadville Public Library ( http://www.meadvillelibrary.org )
>> Crawford County Federated Library System ( http://www.ccfls.org )
>> Mill Run Technology Solutions ( http://millruntech.com )
>>
>> On Thu, Feb 11, 2016 at 5:24 AM, Julian Maurice
>> <julian.maur...@biblibre.com> wrote:
>>>
>>> +1 to "one Koha to rule them all"
>>> +1000 to a more powerful plugin system!
>>> Having a plugin system to build custom tools and reports is great, but I
>>> think we could (and should) go further.
>>>
>>> Le 11/02/2016 10:38, Magnus Enger a écrit :
>>>> Dear Community!
>>>>
>>>> A quote from another thread on koha-devel:
>>>>
>>>> "I look at the code, and beside wondering why that custom feature
>>>> [Norwegian patron DB] is so profoundly imbricated into master Koha, I
>>>> was wondering what is not working."
>>>>
>>>> I think this raises an interesting question. Should we let features
>>>> into Koha that are only of interest to libraries in one or a small
>>>> number of countries? Or should we confine those features to
>>>> country-specific forks?
>>>>
>>>> The quote above implies (I think) that support for the Norwegian
>>>> patron DB should be in a country-specific fork.
>>>>
>>>> On the other hand, the project implementing Koha for public libraries
>>>> in Turkey has been criticized for not integrating their customizations
>>>> into Koha. To which someone replied that the customizations were not
>>>> of much interest to libraries outside Turkey.
>>>>
>>>> So do we want one Koha to rule them all, including country-specific
>>>> features, or do we want one fork per country?
>>>>
>>>> Personally, I prefer the former. In the case of the Norwegian patron
>>>> DB, that is one of the 2-3 "must have" features that all Norwegian
>>>> public libraries will be looking for when they are choosing between
>>>> Koha or some proprietary system. Should we be telling them "Nope, you
>>>> can't use the real Koha, but you can use this fork over here"? That
>>>> will not increase their confidence in choosing Koha, I suspect.
>>>>
>>>> That said, I do think some principles should be applied:
>>>>
>>>> - Strive to make even the country specific features as general as
>>>> possible, so that others can use them as starting points for similar
>>>> features.
>>>>
>>>> - Strive to make the features as unobtrusive as possible.
>>>>
>>>> And maybe, in time, the plugin system can be made powerful enough that
>>>> it can handle some or all of the country-specific features?
>>>>
>>>> Thoughts?
>>>>
>>>> Best regards,
>>>> Magnus Enger
>>>> Libriotech
>>>> ___
>>>> Koha-devel mailing list
>>>> Koha-devel@lists.koha-community.org
>>>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>>>&

Re: [Koha-devel] Playing with NYTProf

[Julian Maurice]

In the last part ("the real real life"), you say 30% of the time is take
by C4::Context::preference, but I don't see where this number comes
from. If I look at the flame graph of the "second profile"
(https://joubu.github.io/koha/nytprof/dbic/nytprofhtml.21326_2/)
C4::Context::preference only takes 2.42%
In the last profile (which is with your patch, right ?),
C4::Context::preference exclusive's time is bigger than any other
subroutines and we spend 9.22s (inclusive) inside
C4::Context::preference for "only" 283 calls, which seems huge.
So... maybe I don't understand correctly NYTProf output, or there is
something wrong with your patch

Le 11/01/2016 15:57, Jonathan Druart a écrit :
> Hi devs,
> 
> I have played with NYTProf at the end of the last week, here is my
> loosely structured notes:
> https://joubu.github.io/koha/nytprof/dbic/index.html
> 
> I have not found big things to implement in order to improve the speed
> but I am wondering if there is not something wrong with the queries
> cache (Search in the page for "Update:")
> 
> Hope to get some feedbacks.
> 
> Cheers,
> Jonathan
> 
> PS: If someone has a better idea to share the profiles, I am open-minded.
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 


-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Debugging in vim

[Julian Maurice]

I do it daily, it's a life changer! :)

But everything seems ok in the wiki. What is the dependency hell you are
talking about ?

Le 30/11/2015 14:35, Barton Chittenden a écrit :
> Hi, has anyone gotten debugging to work in vim, using the instructions here?
> 
> http://wiki.koha-community.org/wiki/Debugging_in_VIM
> 
> I tried it, and ran into dependency hell... If I remember
> correctly, Komodo-PerlRemoteDebugging-4.4.1 didn't play nicely
> with https://github.com/joonty/vdebug.
> 
> If someone *has* gotten this working, I'd like to know how it was done,
> so that I can update the wiki.
> 
> Thanks,
> 
> --Barton
> 
> 
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 


-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] Bug 1993 - Task Scheduler Needs Re-write

[Julian Maurice]

Hi,

Comments in bug 1993 state that using 'at' for task scheduling is bad
for security.

Galen suggests (comment 34) to use a DB table to store a list of jobs,
and check periodically this list with a script in crontab.

I would like to know if someone is already working on something like
that (I didn't find anything in Bugzilla).
If not, do you agree with Galen's proposal as a replacement for the task
scheduler ? Do you have better ideas ?

-- 
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] git commit messages

[Julian Maurice]

Another post (http://chris.beams.io/posts/git-commit/) resumes itself to 
7 rules:


1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how

Rules 1-6 are common to both posts, but I think the 7th is the most 
important: the "what" and "how" can be found in the diff, but never the 
"why".


Another advice from this post on how to write the subject line:

> A properly formed git commit subject line should always be able
> to complete the following sentence:
>
>If applied, this commit will 


Le 23/09/2015 10:29, Colin Campbell a écrit :

Hi,
   can I humbly suggest that we should take a couple of secs to make the
commit messages for submitted patches a bit more useful. When looking at
the history of the code its useful if the summary gives a brief
indication of what has been changed or added by the commit. Good
summaries can save a lot of frustrated time wasting when trying to track
down where a change has been introduced.
Although we flag up the bugzilla bug in the summary, just echoing the
bug summary is nearly always counter-productive. The commit should
indicate the change introduced not the bug that prompted it. Once the
patch is applied the original bug is "background reading" not the main
event. It is also misleading if the commit summary says "X is broken"
then when that is extracted into the release notes or the gitlog it
looks like the commit introduces the breakage of x not vice-versa. It is
surely better to have the commit say something along the lines of
"Fix broken behaviour in X", which makes it sound a bit more like the
desirable feature it no doubt is.

A long standing succinct post on commit messages is

http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

Colin
(Author of some of the world's worst commit messages)




--
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] RESTful Apis

[Julian Maurice]

It has been decided during the dev meeting to push first a minimal 
version of the API code, which will handle only one type of 
authentication (cookie), and work in CGI mode.

Then we will start to build the rest on top of that.
So I cleaned up the bug 13799, which I think is now as simple as it can 
be, and is waiting for signoffs.


However, my last comment 
(http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13799#c147) 
raises a few concerns that need to be addressed first. It's about 
including a patch that uses a Swagger2 feature marked as experimental.




Le 20/09/2015 02:11, Brendan Gallagher a écrit :

Hi All -

For those of you in the know, can we get a public update of where we are
with this?  I believe we had some new action items out of the last IRC
dev meeting, and I'm curious as to what we've met so far.  Also there
was some discussion/difficulty with perhaps having to run something
(mojolicous iirc) as a daemon vs not having to.  (I think maybe Tomas
was going to help with the technical difficulty on that.

I'm just looking for updates on this whole thing.  We've got some
excited thoughts, ideas, and plans to use these APIs asap.

Oh yeah BTW Elastic is completely developed and ready.  We need tons of
testing etc. and reports to Robin for "tweaking" the code for the
results we are looking for.  Please if you have time - test ES and send
your feedback.  We've got sometime left for this to be an option for the
next release (and the RESTapis too).

Thanks much,
Brendan Gallagher

--
---
Brendan A. Gallagher
ByWater Solutions
CEO

Support and Consulting for Open Source Software
Installation, Data Migration, Training, Customization, Hosting
and Complete Support Packages
Headquarters: Santa Barbara, CA - Office: Redding, CT
Phone # (888) 900-8944
http://bywatersolutions.com
i...@bywatersolutions.com <mailto:i...@bywatersolutions.com>


___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/




--
Julian Maurice <julian.maur...@biblibre.com>
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] New RESTful API

[Julian Maurice]

Hi all,

During the hackfest in Marseille, we talked a lot about the new RESTful 
API and how to integrate it into Koha.


Discussions have been summarized in the wiki page [1], in particular in 
sections Suggested way forward and API Protocol Specification.


A proof-of-concept patch was made and is attached to Bug 13799 [2].
It uses Mojolicious and its Swagger2 plugin (more details on the wiki page).
This will be used as a base for building the API. So, please have a look 
at it and report any problem you can think of.



[1] http://wiki.koha-community.org/wiki/New_REST_API_RFC
[2] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13799

--
Julian Maurice julian.maur...@biblibre.com
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] Git tip of the day: taille de tabulation dans git diff

[Julian Maurice]

Dans bokeh on a souvent du code aligné avec des tabulations, par exemple:

$exemplaires = Class_Exemplaire::findAllBy(['id_notice' = $id_notice,
'id_int_bib' = 
$this-id_int_bib,
'code_barres' = 
$ex['code_barres']]);



Comme la taille de tabulation dans nos éditeurs est de 2 et que par 
défaut dans git diff, elle est de 8, on doit souvent scroller à droite 
pour voir tout le code.


Pour éviter ça, et dire à git d'afficher des tabs de 2:

git config core.pager 'less -x2'

(peut aussi se faire avec la variable d'environnement LESS à priori)

--
Julian Maurice julian.maur...@biblibre.com
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Git tip of the day: taille de tabulation dans git diff

[Julian Maurice]

Le 08/08/2014 10:43, Julian Maurice a écrit :

Dans bokeh on a souvent du code aligné avec des tabulations, par exemple:

$exemplaires = Class_Exemplaire::findAllBy(['id_notice' = $id_notice,
 'id_int_bib' =
$this-id_int_bib,
 'code_barres' =
$ex['code_barres']]);


Comme la taille de tabulation dans nos éditeurs est de 2 et que par
défaut dans git diff, elle est de 8, on doit souvent scroller à droite
pour voir tout le code.

Pour éviter ça, et dire à git d'afficher des tabs de 2:

 git config core.pager 'less -x2'

(peut aussi se faire avec la variable d'environnement LESS à priori)



Oops, sorry! Wrong email address :)

--
Julian Maurice julian.maur...@biblibre.com
BibLibre
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/