From dcook at prosentient.com.au  Wed Aug  4 08:25:03 2021
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Wed, 4 Aug 2021 16:25:03 +1000
Subject: [Koha-devel] Advanced Editor for Authority Records
Message-ID: <0e9601d788f9$76194200$624bc600$@prosentient.com.au>

Hi all,

 

Does anyone know why the Advanced Editor in cataloguing is only for
bibliographic records and not for authority records as well?

 

Does anyone know if there is work to add an Advanced Editor for the
authority records too?

 

Thanks,

 

David Cook

Senior Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

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

From clopez at dml.vic.edu.au  Wed Aug  4 08:48:50 2021
From: clopez at dml.vic.edu.au (Carlos Lopez)
Date: Wed, 4 Aug 2021 06:48:50 +0000
Subject: [Koha-devel] Advanced Editor for Authority Records
In-Reply-To: <0e9601d788f9$76194200$624bc600$@prosentient.com.au>
References: <0e9601d788f9$76194200$624bc600$@prosentient.com.au>
Message-ID: <MEYPR01MB741752A22C572FFA28D5D778A2F19@MEYPR01MB7417.ausprd01.prod.outlook.com>

Hi David

Funny you should ask ...

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

c.

With kind regards from the Dalton McCaughey Library Team

Carlos Lopez

Dalton McCaughey Library | 29 College Crescent, Parkville, VICTORIA 3052
Ph: 03 9340 8888 ext.1 | library at dml.vic.edu.au<mailto:library at dml.vic.edu.au> | library.dmlibrary.org.au

From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of dcook at prosentient.com.au
Sent: Wednesday, 4 August 2021 4:25 PM
To: 'Koha Devel' <koha-devel at lists.koha-community.org>
Subject: [Koha-devel] Advanced Editor for Authority Records

Hi all,

Does anyone know why the Advanced Editor in cataloguing is only for bibliographic records and not for authority records as well?

Does anyone know if there is work to add an Advanced Editor for the authority records too?

Thanks,

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

Office: 02 9212 0899
Online: 02 8005 0595

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20210804/5b95d8a8/attachment.htm>

From mtj at kohaaloha.com  Sat Aug  7 00:44:40 2021
From: mtj at kohaaloha.com (Mason James)
Date: Sat, 7 Aug 2021 10:44:40 +1200
Subject: [Koha-devel] =?utf-8?q?Koha_packages_are_available_=F0=9F=8E=81?=
Message-ID: <3d0b1428-aa5e-1c51-462c-1000fb6cbcfb@kohaaloha.com>

kia ora community,
the latest Koha packages are available

cheers, Mason

From fridolin.somers at biblibre.com  Tue Aug 10 23:33:41 2021
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Tue, 10 Aug 2021 11:33:41 -1000
Subject: [Koha-devel] Check of syspref editor with DB columns
Message-ID: <20d38b1d-c6ec-59a5-51c1-3879e80254e3@biblibre.com>

Hi,

Since 22844, preferences like BorrowerUnwantedField and 
BorrowerMandatoryField show a modal selection of DB columns.
This relies on 
/koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/borrowers.json


Unwanted fields are hidden in template using :
   [% UNLESS nofield %]
Mandatory fields have attribute require in template using :
   [% IF mandatoryfield %]

Big problem is how do we maintain this ???

For example I see in template memberentrygen.tt :
   [% UNLESS noautorenew_checkouts %]
But this column is not in borrowers.json :(

I'm made some checks :
grep '% UNLESS no' 
koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt | awk 
-F 'UNLESS ' '{print $2}' | tr -d '%]' | sort -u
egrep 'mandatory\w' 
koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt | awk 
-F 'mandatory' '{print $2}' | tr -d ' %])' | sort -u
Plus some manual work.

My conclusion :

Are missing from borrowers.json (used by nofield and/or mandatoryfield) :
   - autorenew_checkouts
   - relationship
   - sms_provider_id
   - sort1
   - sort2

Are useless in borrowers.json :
   - categorycode : obviously mandatory ?
   - smsalertnumber : in form the field is now SMSnumber, but no 
noSMSnumber/mandarorySMSnumber in template

I will create a bug report for autorenew_checkouts first.

Maybe we could add something in QA tools ?

Best regards,

PS :
Also not very clear, BorrowerMandatoryField shows all fields but in 
template there is only :
mandatoryborrowernotes
mandatorycardnumber
mandatorycontactfirstname
mandatorycontactname
mandatorydateenrolled
mandatorydateexpiry
mandatorydateofbirth
mandatoryemail
mandatoryemailpro
mandatoryfax
mandatoryfirstname
mandatoryinitials
mandatorymobile
mandatoryopacnote
mandatoryothernames
mandatorypassword
mandatoryphone
mandatoryphonepro
mandatoryprimary_contact_method
mandatorysort1
mandatorysort2
mandatorysurname
mandatorytitle
mandatoryuserid
mandatorypassword

We should add other fields in exclusions ?

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
Software and system maintainer 🦄
BibLibre, France

From fridolin.somers at biblibre.com  Wed Aug 11 00:56:33 2021
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Tue, 10 Aug 2021 12:56:33 -1000
Subject: [Koha-devel] Zebra Trivia
In-Reply-To: <032c01d77e89$4bdccd60$e3966820$@prosentient.com.au>
References: <032c01d77e89$4bdccd60$e3966820$@prosentient.com.au>
Message-ID: <4b569fb8-fd53-fbdd-5e75-0e189b192270@biblibre.com>

Beuuuuuu (sound of a GNU looking at a Zebra).

Why on earth is there this 4=6 in ccl.properties ?
THis is usefull for field type (date, numeric ...) or truncation, but 
never for phrase/wrdl ...

The (only) doc from Indexdata :
https://software.indexdata.com/zebra/doc/querymodel-rpn.html#querymodel-bib1-structure

Best regards,

Le 21/07/2021 à 13:36, dcook at prosentient.com.au a écrit :
> Hi all,
> 
> Today I learned (or maybe re-learned) something about Zebra CCL syntax:
> 
> “Identifier-standard,phr” does not do a phrase search. It does a word 
> list search. Now you might this this is impossible, but it’s not, 
> because Identifier-standard is hard-coded with 4=6 in ccl.properties: 
> Identifier-standard  1=1007 4=6
> 
> Since Identifier-standard has already set the “4” structure attribute, 
> “phr” does nothing.u
> 
> However, if you write “phr,Identifier-standard”, it will do a phrase 
> search. That’s because the “phr” sets the “4” structure attribute before 
> the “Identifier-standard” gets converted into PQF/RPN.
> 
> Cool, n’est-ce pas?
> 
> David Cook
> 
> Senior Software Engineer
> 
> Prosentient Systems
> 
> Suite 7.03
> 
> 6a Glen St
> 
> Milsons Point NSW 2061
> 
> Australia
> 
> Office: 02 9212 0899
> 
> Online: 02 8005 0595
> 
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
> 

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
Software and system maintainer 🦄
BibLibre, France

From fridolin.somers at biblibre.com  Wed Aug 11 01:04:09 2021
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Tue, 10 Aug 2021 13:04:09 -1000
Subject: [Koha-devel] Bug 17600 (Standardize the EXPORT) is pushed
In-Reply-To: <CAJzKNY5xamJzP-R_2S01xsEJjjyYHabEMit0bXDVYbQqG+O7KQ@mail.gmail.com>
References: <CAJzKNY5xamJzP-R_2S01xsEJjjyYHabEMit0bXDVYbQqG+O7KQ@mail.gmail.com>
Message-ID: <79b769c4-172d-a12e-d38c-3e5bfb8eb501@biblibre.com>

Hi,

Do we need to impact Koha plugins ?

Best regards,

Le 15/07/2021 à 21:02, Jonathan Druart a écrit :
> Hi,
> I've just pushed bug 17600, it's a massive patch (1311 files changed,
> 4077 insertions(+), 4362 deletions(-)) that will cause conflicts with
> a lot of other patches in the queue.
> 
> I've described in the commit message what it is doing, please read it.
> 
> Most of the time the changes it brings are trivial but be careful when
> you resolve the conflicts. Ping me if you need help.
> 
> Enjoy your weekend!
> Jonathan
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
> 

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
Software and system maintainer 🦄
BibLibre, France

From dcook at prosentient.com.au  Wed Aug 11 01:56:45 2021
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Wed, 11 Aug 2021 09:56:45 +1000
Subject: [Koha-devel] Check of syspref editor with DB columns
In-Reply-To: <20d38b1d-c6ec-59a5-51c1-3879e80254e3@biblibre.com>
References: <20d38b1d-c6ec-59a5-51c1-3879e80254e3@biblibre.com>
Message-ID: <032901d78e43$60455af0$20d010d0$@prosentient.com.au>

Good questions, Fridolin. I ended up adding sort1 and sort2 locally to borrowers.json. I've been so busy I hadn't even thought of upstreaming yet I think. 



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

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Fridolin SOMERS
Sent: Wednesday, 11 August 2021 7:34 AM
To: koha-devel <koha-devel at lists.koha-community.org>
Subject: [Koha-devel] Check of syspref editor with DB columns

Hi,

Since 22844, preferences like BorrowerUnwantedField and BorrowerMandatoryField show a modal selection of DB columns.
This relies on
/koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/borrowers.json


Unwanted fields are hidden in template using :
   [% UNLESS nofield %]
Mandatory fields have attribute require in template using :
   [% IF mandatoryfield %]

Big problem is how do we maintain this ???

For example I see in template memberentrygen.tt :
   [% UNLESS noautorenew_checkouts %]
But this column is not in borrowers.json :(

I'm made some checks :
grep '% UNLESS no' 
koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt | awk -F 'UNLESS ' '{print $2}' | tr -d '%]' | sort -u egrep 'mandatory\w' 
koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt | awk -F 'mandatory' '{print $2}' | tr -d ' %])' | sort -u Plus some manual work.

My conclusion :

Are missing from borrowers.json (used by nofield and/or mandatoryfield) :
   - autorenew_checkouts
   - relationship
   - sms_provider_id
   - sort1
   - sort2

Are useless in borrowers.json :
   - categorycode : obviously mandatory ?
   - smsalertnumber : in form the field is now SMSnumber, but no noSMSnumber/mandarorySMSnumber in template

I will create a bug report for autorenew_checkouts first.

Maybe we could add something in QA tools ?

Best regards,

PS :
Also not very clear, BorrowerMandatoryField shows all fields but in template there is only :
mandatoryborrowernotes
mandatorycardnumber
mandatorycontactfirstname
mandatorycontactname
mandatorydateenrolled
mandatorydateexpiry
mandatorydateofbirth
mandatoryemail
mandatoryemailpro
mandatoryfax
mandatoryfirstname
mandatoryinitials
mandatorymobile
mandatoryopacnote
mandatoryothernames
mandatorypassword
mandatoryphone
mandatoryphonepro
mandatoryprimary_contact_method
mandatorysort1
mandatorysort2
mandatorysurname
mandatorytitle
mandatoryuserid
mandatorypassword

We should add other fields in exclusions ?

--
Fridolin SOMERS <fridolin.somers at biblibre.com> Software and system maintainer 🦄
BibLibre, France
_______________________________________________
Koha-devel mailing list
Koha-devel at 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/



From dcook at prosentient.com.au  Wed Aug 11 01:58:21 2021
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Wed, 11 Aug 2021 09:58:21 +1000
Subject: [Koha-devel] Zebra Trivia
In-Reply-To: <4b569fb8-fd53-fbdd-5e75-0e189b192270@biblibre.com>
References: <032c01d77e89$4bdccd60$e3966820$@prosentient.com.au>
 <4b569fb8-fd53-fbdd-5e75-0e189b192270@biblibre.com>
Message-ID: <032a01d78e43$9995bfc0$ccc13f40$@prosentient.com.au>

Hahaha. That made my morning, Frido.

I have no idea why Identifier-standard is set up that way. It might be worth doing a git-blame at some point. 

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

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Fridolin SOMERS
Sent: Wednesday, 11 August 2021 8:57 AM
To: koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] Zebra Trivia

Beuuuuuu (sound of a GNU looking at a Zebra).

Why on earth is there this 4=6 in ccl.properties ?
THis is usefull for field type (date, numeric ...) or truncation, but never for phrase/wrdl ...

The (only) doc from Indexdata :
https://software.indexdata.com/zebra/doc/querymodel-rpn.html#querymodel-bib1-structure

Best regards,

Le 21/07/2021 à 13:36, dcook at prosentient.com.au a écrit :
> Hi all,
> 
> Today I learned (or maybe re-learned) something about Zebra CCL syntax:
> 
> “Identifier-standard,phr” does not do a phrase search. It does a word 
> list search. Now you might this this is impossible, but it’s not, 
> because Identifier-standard is hard-coded with 4=6 in ccl.properties:
> Identifier-standard  1=1007 4=6
> 
> Since Identifier-standard has already set the “4” structure attribute, 
> “phr” does nothing.u
> 
> However, if you write “phr,Identifier-standard”, it will do a phrase 
> search. That’s because the “phr” sets the “4” structure attribute 
> before the “Identifier-standard” gets converted into PQF/RPN.
> 
> Cool, n’est-ce pas?
> 
> David Cook
> 
> Senior Software Engineer
> 
> Prosentient Systems
> 
> Suite 7.03
> 
> 6a Glen St
> 
> Milsons Point NSW 2061
> 
> Australia
> 
> Office: 02 9212 0899
> 
> Online: 02 8005 0595
> 
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
> 

--
Fridolin SOMERS <fridolin.somers at biblibre.com> Software and system maintainer 🦄
BibLibre, France
_______________________________________________
Koha-devel mailing list
Koha-devel at 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/



From jonathan.druart at bugs.koha-community.org  Wed Aug 11 11:48:28 2021
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Wed, 11 Aug 2021 11:48:28 +0200
Subject: [Koha-devel] Bug 17600 (Standardize the EXPORT) is pushed
In-Reply-To: <79b769c4-172d-a12e-d38c-3e5bfb8eb501@biblibre.com>
References: <CAJzKNY5xamJzP-R_2S01xsEJjjyYHabEMit0bXDVYbQqG+O7KQ@mail.gmail.com>
 <79b769c4-172d-a12e-d38c-3e5bfb8eb501@biblibre.com>
Message-ID: <CAJzKNY6BNUNPfGyA0tKR-R86_WKSR_Sdh8rsSKaqys8a_zhxfg@mail.gmail.com>

It may break plugins using modules that were using EXPORT and now EXPORT_OK

Le mer. 11 août 2021 à 01:04, Fridolin SOMERS <fridolin.somers at biblibre.com>
a écrit :

> Hi,
>
> Do we need to impact Koha plugins ?
>
> Best regards,
>
> Le 15/07/2021 à 21:02, Jonathan Druart a écrit :
> > Hi,
> > I've just pushed bug 17600, it's a massive patch (1311 files changed,
> > 4077 insertions(+), 4362 deletions(-)) that will cause conflicts with
> > a lot of other patches in the queue.
> >
> > I've described in the commit message what it is doing, please read it.
> >
> > Most of the time the changes it brings are trivial but be careful when
> > you resolve the conflicts. Ping me if you need help.
> >
> > Enjoy your weekend!
> > Jonathan
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel at 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/
> >
>
> --
> Fridolin SOMERS <fridolin.somers at biblibre.com>
> Software and system maintainer 🦄
> BibLibre, France
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : https://www.koha-community.org/
> git : https://git.koha-community.org/
> bugs : https://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20210811/aae5a225/attachment-0001.htm>

From oleonard at myacpl.org  Wed Aug 11 19:40:47 2021
From: oleonard at myacpl.org (Owen Leonard)
Date: Wed, 11 Aug 2021 13:40:47 -0400
Subject: [Koha-devel] Replacing jQueryUI autocomplete
Message-ID: <CAO4qe2PLWAjTfi9dTxpr_uoygPfyO8rfCY4O5==LdaBqziGNyA@mail.gmail.com>

We're making progress towards a replacement for the jQueryUI
datepicker component: Bug 28376, "Replace obsolete
jquery-ui-timepicker-addon"
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28376

I think it would be a good idea to look at replacing the rest of the
jQueryUI components we use, since jQueryUI appears to be a dead
project. I've been looking at this as a replacement for jQueryUI's
autocomplete:

https://tarekraafat.github.io/autoComplete.js/

It's small, seems fast, and has been around for several years, with
its last release happening last month. I'm still testing whether it's
missing any functionality we need, but I thought before I get too far
I would ask:

Does anyone have any experience with this project?

Does anyone have any other autocomplete libraries they've used and
would recommend?

Thanks,

  Owen

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

From dcook at prosentient.com.au  Thu Aug 12 02:12:14 2021
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Thu, 12 Aug 2021 10:12:14 +1000
Subject: [Koha-devel] Replacing jQueryUI autocomplete
In-Reply-To: <CAO4qe2PLWAjTfi9dTxpr_uoygPfyO8rfCY4O5==LdaBqziGNyA@mail.gmail.com>
References: <CAO4qe2PLWAjTfi9dTxpr_uoygPfyO8rfCY4O5==LdaBqziGNyA@mail.gmail.com>
Message-ID: <004901d78f0e$b45b85d0$1d129170$@prosentient.com.au>

Sadly, I don't have anything useful to add about autocomplete libraries, but you've sent me down an interesting rabbit hole about jQuery UI! 

I won't bore you with my journey, but after reading through a few big conversations I wound up at the jQuery UI Github and I was surprised that there's been a lot of activity: https://github.com/jquery/jquery-ui/commits/main. There's even a new alpha release: https://github.com/jquery/jquery-ui/releases. 

Everything was done by Michał Gołębiowski-Owczarek and looking into him led me to this really interesting write up: https://github.com/readme/stories/michal-golebiowski-owczarek

Probably still a good idea to move away from jquery-ui as it probably is dead, but interesting to see him breathing some life into the project after 5 years of dormancy. 

I'm tempted to shoot him a Twitter DM to see what his plans are. 

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

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Owen Leonard
Sent: Thursday, 12 August 2021 3:41 AM
To: Koha Devel <koha-devel at lists.koha-community.org>
Subject: [Koha-devel] Replacing jQueryUI autocomplete

We're making progress towards a replacement for the jQueryUI datepicker component: Bug 28376, "Replace obsolete jquery-ui-timepicker-addon"
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28376

I think it would be a good idea to look at replacing the rest of the jQueryUI components we use, since jQueryUI appears to be a dead project. I've been looking at this as a replacement for jQueryUI's
autocomplete:

https://tarekraafat.github.io/autoComplete.js/

It's small, seems fast, and has been around for several years, with its last release happening last month. I'm still testing whether it's missing any functionality we need, but I thought before I get too far I would ask:

Does anyone have any experience with this project?

Does anyone have any other autocomplete libraries they've used and would recommend?

Thanks,

  Owen

--
Web Developer
Athens County Public Libraries
(740) 737-6006
https://www.myacpl.org
_______________________________________________
Koha-devel mailing list
Koha-devel at 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/



From dcook at prosentient.com.au  Thu Aug 12 08:45:14 2021
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Thu, 12 Aug 2021 16:45:14 +1000
Subject: [Koha-devel] Previewing editor content in "News"
Message-ID: <00a601d78f45$9ae519e0$d0af4da0$@prosentient.com.au>

Hi all,

 

Lately, I've been thinking that it would be great if we could preview
content from WYSIWYG editors in context before saving and showing it live.

 

Content Management Systems and Wikis usually let you do that, and I think it
would be really useful. I know that I've had at least a few librarians
complain about how their News content looks different in the OPAC than it
does in the News function, and I don't really have an answer except "sorry"
at the moment.

 

This would actually be useful for OpacUserCSS and OpacUserJS as well.

 

Looking at Media Wiki, it looks like it uses a "wpEditToken" value, so the
data must be saved, and then fetched using the token. 

 

I think it would be harder for Koha than Media Wiki (especially for system
preferences and News for specific libraries), but I think it would be
useful. 

 

Unfortunately, I don't have the resources to work on this, but maybe someone
else does. 

 

David Cook

Senior Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

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

From kohanews at gmail.com  Fri Aug 13 09:47:49 2021
From: kohanews at gmail.com (Koha Newsletter)
Date: Fri, 13 Aug 2021 09:47:49 +0200
Subject: [Koha-devel] Call for news - Newsletter August 2021
Message-ID: <CAEqgz_ni+SYSwYpsEKpXjBu0ZNnwT0C-FCVAa=wmcMR0TU4Tyg@mail.gmail.com>

Hi

I'm collecting news for the August 2021 Koha Community Newsletter.
Please send anything noteworthy to:

kohanews (at) gmail (dot) com

News criteria:
* News items can be of any length.
* Images are fine.
* Anything and everything Koha.
* Submit by the 26th of the month.

Text format criteria:
* Just structured plain text, or
* HTML text to include tables or similar

For events:
* Consider adding your event to the Koha Community calendar at
https://koha-community.org/calendar/

Thank you!

Michael Kuhn
Editor, Koha Community Newsletter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20210813/ed6b6110/attachment.htm>

From jessekah at edgetech.com.my  Mon Aug 16 10:13:08 2021
From: jessekah at edgetech.com.my (JESSE KAH)
Date: Mon, 16 Aug 2021 16:13:08 +0800
Subject: [Koha-devel] [Koha] Call for news - Newsletter August 2021
In-Reply-To: <CAEqgz_ni+SYSwYpsEKpXjBu0ZNnwT0C-FCVAa=wmcMR0TU4Tyg@mail.gmail.com>
References: <CAEqgz_ni+SYSwYpsEKpXjBu0ZNnwT0C-FCVAa=wmcMR0TU4Tyg@mail.gmail.com>
Message-ID: <992EBE5D-7F1C-41C4-B476-9A3845E9A17A@edgetech.com.my>

Dear Michael,

 

Good day!

This is Jesse from Lemonjar Software Media Sdn. Bhd., Malaysia.

We have few implementation of Koha site in Malaysia and would like to share with the community as follow:

 

1. The Federal Court of Malaysia

     Koha version 19.11 (bi-language: English and Bahasa Malaysia)

     Their OPAC is open for public to do searching via - https://libkoha.kehakiman.gov.my/ 

     However, login is only available for the staff of Federal Court of Malaysia via Active Directory login.

 

2. The Attorney General of the state of Sabah, Malaysia

     Koha version 20.05 

     Their searching in OPAC is ready only for internal Attorney General's access after login - https://sagclibrary.sabah.gov.my/ 

 

3. Library of the Ministry of National Unity

    Koha version 20.05 (bi-language: English and Bahasa Malaysia)

    Their OPAC is open for public to do searching via - http://pusatsumber.perpaduan.gov.my/.

 

4. Malaysia Institute of Architects (PAM)

    Koha version 18.11

    Implementation of Koha is done some times ago, however their OPAC is recently open for public access with re-designed new look.

    The searching in OPAC is closed and only available for registered architects to their organization, and self-registration is available via OPAC.

    PAM OPAC can be access via: http://library.pam.org.my:8000/ 

 

 

Thanks & have a blessing day!

 

 

Stay safe and alert to fight against Covid-19

 

 

Best Regards,

(Mdm.) Jesse Kah

Lemonjar Software Media Sdn. Bhd.

-- Managing Director --

Mobile: +6 (016) 8606 826

Tel: +6 (03)7859 9226 (Selangor Office) | +6 (088) 713226 (Sabah office)

Fax: +6 (088) 713226

Website:  https://www.lemonjar.com.my  

                  https://www.edgetech.com.my 

                https://www.czur.my 

Other Email: lemonjarsm at gmail.com / lemonjar.sales at gmail.com 

 

 

Lemonjar Facebook page: https://www.facebook.com/lemonjarsoftmed/

Czur Facebook page: https://www.facebook.com/CZURMalaysia   

Edgetech Facebook page: https://www.facebook.com/edgetechengineering/ 

YouTube page: https://www.youtube.com/channel/UCLV34OjYVdG6KQK_uTC2f3A/featured 

 

 

Disclamer: Any reproduction, dissemination, copying, disclosure, modification, distribution and keeping of this message, without prior written consent of the sender are strictly prohibited.

 

Lemonjar Software Media Sdn. Bhd. and Edge Tech Engineering Is specialising in manufacturing comprehensive solution in Library Automation Equipment Products – EM, RFID (HF/ UHF) and Hybrid solution; As well as having 12-years experiences in Open Source KOHA ILS System including customization and software development; as well as other Open Source system solutions specifically for Library.

 

Edge Tech Engineering also specializes in the reselling, marketing and distribution of many prestigious and leading brands of ICT products, namely, HP, Acer, Dell, Asus, APC, Autodesk, Epson, Supermicro, Intel, Lenovo, Microsoft, Huawei, Symantec, Yes, Aruba, Cisco, Fujitsu, IBM, Intermec, Juniper, Oracle, Trend Micro, BitDefender, VMWare, Brother, Canon, Zebra Motorola and others.

 

Czur Malaysia is Smart Scanner solutions range from Shine Series, Aurora Series, ET Series and M Series all come with auto OCR processing features.

 

 

 

On 13/08/2021, 3:47 PM, "Koha on behalf of Koha Newsletter" <koha-bounces at lists.katipo.co.nz on behalf of kohanews at gmail.com> wrote:

 

    Hi

 

    I'm collecting news for the August 2021 Koha Community Newsletter.

    Please send anything noteworthy to:

 

    kohanews (at) gmail (dot) com

 

    News criteria:

    * News items can be of any length.

    * Images are fine.

    * Anything and everything Koha.

    * Submit by the 26th of the month.

 

    Text format criteria:

    * Just structured plain text, or

    * HTML text to include tables or similar

 

    For events:

    * Consider adding your event to the Koha Community calendar at

    https://koha-community.org/calendar/

 

    Thank you!

 

    Michael Kuhn

    Editor, Koha Community Newsletter

    _______________________________________________

 

    Koha mailing list  http://koha-community.org

    Koha at lists.katipo.co.nz

    Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

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

From fridolin.somers at biblibre.com  Mon Aug 16 21:07:10 2021
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Mon, 16 Aug 2021 09:07:10 -1000
Subject: [Koha-devel] Time to translate: string freeze to prepare 20.11.09
 release
Message-ID: <c11f86d5-9afc-a4f5-4b8d-280892a7b660@biblibre.com>

Hi,

String freeze is into effect 🥶

The 20.11.x maintenance branch is preparing for 20.11.09 release 📦
The release is scheduled for around the 23.

This means it's the right time to head over to the translation platform:
https://translate.koha-community.org/projects/

Keep in mind that translations must be done with priority on higher 
version 21.05 🔥

Happy translating 🌎🌍🌏

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
Software and system maintainer 🦄
BibLibre, France

From philippe.blouin at inlibro.com  Mon Aug 16 23:17:22 2021
From: philippe.blouin at inlibro.com (Philippe Blouin)
Date: Mon, 16 Aug 2021 17:17:22 -0400
Subject: [Koha-devel] systemd version of koha-plack-ctl.sh ?
Message-ID: <21e683ce-bdb3-cf2f-4b9c-e1d03b40b265@inlibro.com>

Hello all!

Has anyone been through the effort of coding a systemd unit file for 
Koha's plack ?

I'm currently using an override.conf to specify some timeout values, and 
that got me wondering (or wanting) about one.

Curiosity....

Thanks!

-- 
Philippe Blouin,
Directeur de la technologie

Tél.  : (833) 465-4276, poste 230
philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20210816/6af793e4/attachment.htm>

From victor at tuxayo.net  Tue Aug 17 00:44:24 2021
From: victor at tuxayo.net (Victor Grousset/tuxayo)
Date: Tue, 17 Aug 2021 00:44:24 +0200
Subject: [Koha-devel] Time to translate: string freeze to prepare Koha
 20.05.15 has begun
Message-ID: <c98188f9-816a-2611-d72c-07b41af95bbb@tuxayo.net>

Hi, saluton, hola, bonjour,

String freeze is into effect as of now for the 20.05.x maintenance branch.
The minor release is scheduled for around the 23th.

This means it's the right time to head over to the translation platform:
https://translate.koha-community.org/projects/

Reminder: if you add or change a translation in version 20.05,
then you must also copy it to 20.11 and 21.05.
Otherwise your work will be lost for future versions.


Happy translating :)

-- 
Victor Grousset/tuxayo

From dcook at prosentient.com.au  Tue Aug 17 01:15:50 2021
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Tue, 17 Aug 2021 09:15:50 +1000
Subject: [Koha-devel] systemd version of koha-plack-ctl.sh ?
In-Reply-To: <21e683ce-bdb3-cf2f-4b9c-e1d03b40b265@inlibro.com>
References: <21e683ce-bdb3-cf2f-4b9c-e1d03b40b265@inlibro.com>
Message-ID: <025801d792f4$a7554da0$f5ffe8e0$@prosentient.com.au>

I don’t know of any file called “koha-plack-ctl.sh”?

 

As for systemd, while I’ve previously used systemd with Koha, I try to avoid it these days, since different environments will have different init systems. For example, your average Docker container doesn’t have an init system running. Recently, we also have set up Koha on Ubuntu for Windows using the Windows Subsystem for Linux 2, which also has a custom init system. 

 

Tell us more about what you’re trying to do? I always like thinking about different deployment scenarios. 

 

David Cook

Senior Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Philippe Blouin
Sent: Tuesday, 17 August 2021 7:17 AM
To: koha-devel <koha-devel at lists.koha-community.org>
Subject: [Koha-devel] systemd version of koha-plack-ctl.sh ?

 

Hello all!

Has anyone been through the effort of coding a systemd unit file for Koha's plack ?

I'm currently using an override.conf to specify some timeout values, and that got me wondering (or wanting) about one.

Curiosity....

Thanks!

-- 

Philippe Blouin,
Directeur de la technologie

Tél.  : (833) 465-4276, poste 230
 <mailto:philippe.blouin at inLibro.com> philippe.blouin at inLibro.com 

inLibro | pour esprit libre |  <http://www.inLibro.com> www.inLibro.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20210817/8648f976/attachment.htm>

From jonathan.druart at bugs.koha-community.org  Tue Aug 17 11:16:55 2021
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Tue, 17 Aug 2021 11:16:55 +0200
Subject: [Koha-devel] Improvement of our upgrade process
Message-ID: <CAJzKNY7Jxrv=5hwnExU+Oh7TXjiFfPnjgHU+S4nKGajE5GP-4A@mail.gmail.com>

Hi devs,

Bug 25078 was pushed yesterday and it modifies how we deal with our upgrade
process.

I adjusted the wiki page -
https://wiki.koha-community.org/wiki/Database_updates

The different things to know about it:
* The skeleton for atomic updates is modified [1]
* On push the atomic updates are no longer appended to updatedatabase.pl
but moved to a new db_revs directory (named by version, like 210600016.pl
for the entry 21.06.00.016)
* Versions from 21.06.00.000 have been migrated to use this new mechanism,
older are still in updatabase.pl
* updatabase.pl is still the script to call if you want to upgrade the DB
* Each DB rev (and atomic update) is executed in a transaction that
rollbacks and stop the upgrade process if something went wrong
* Old atomicupdate format will still work (but require more work for the RM)
* Better error handling and better warnings possible
* Nicer UI during the upgrade step (step3)

Let me know if you have any questions!

Cheers,
Jonathan

[1]
https://git.koha-community.org/Koha-community/Koha/src/commit/85c395460687f7e359417711b6facd42e0a24f8f/installer/data/mysql/atomicupdate/skeleton.pl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20210817/5b4a4251/attachment.htm>

From kohanews at gmail.com  Tue Aug 17 23:53:55 2021
From: kohanews at gmail.com (Koha Newsletter)
Date: Tue, 17 Aug 2021 23:53:55 +0200
Subject: [Koha-devel] [Koha] Call for news - Newsletter August 2021
In-Reply-To: <992EBE5D-7F1C-41C4-B476-9A3845E9A17A@edgetech.com.my>
References: <CAEqgz_ni+SYSwYpsEKpXjBu0ZNnwT0C-FCVAa=wmcMR0TU4Tyg@mail.gmail.com>
 <992EBE5D-7F1C-41C4-B476-9A3845E9A17A@edgetech.com.my>
Message-ID: <CAEqgz_nLzVwiNJT_nkTSGueXV=yu6ygeOpA2F+E8kBrOABBGcw@mail.gmail.com>

Hi Jesse

Thanks for your e-mail!

Did any of the mentioned four libraries go live in the last 1-3 months? If
not then they do not qualify for the newsletter (which should contain news,
of course). However, you could always add your implementations of Koha at
https://wiki.koha-community.org/wiki/KohaUsers/SoutheastAsia

Best wishes: MIchael

On Mon, Aug 16, 2021 at 10:13 AM JESSE KAH <jessekah at edgetech.com.my> wrote:

> *Dear Michael,*
>
>
>
> Good day!
>
> This is Jesse from Lemonjar Software Media Sdn. Bhd., Malaysia.
>
> We have few implementation of Koha site in Malaysia and would like to
> share with the community as follow:
>
>
>
> *1. The Federal Court of Malaysia*
>
>      Koha version 19.11 (bi-language: English and Bahasa Malaysia)
>
>      Their OPAC is open for public to do searching via -
> https://libkoha.kehakiman.gov.my/
>
>      However, login is only available for the staff of Federal Court of
> Malaysia via Active Directory login.
>
>
>
> *2. The Attorney General of the state of Sabah, Malaysia*
>
>      Koha version 20.05
>
>      Their searching in OPAC is ready only for internal Attorney General's
> access after login - https://sagclibrary.sabah.gov.my/
>
>
>
> *3. Library of the Ministry of National Unity*
>
>     Koha version 20.05 (bi-language: English and Bahasa Malaysia)
>
>     Their OPAC is open for public to do searching via -
> http://pusatsumber.perpaduan.gov.my/.
>
>
>
> *4. Malaysia Institute of Architects (PAM)*
>
>     Koha version 18.11
>
>     Implementation of Koha is done some times ago, however their OPAC is
> recently open for public access with re-designed new look.
>
>     The searching in OPAC is closed and only available for registered
> architects to their organization, and self-registration is available via
> OPAC.
>
>     PAM OPAC can be access via: http://library.pam.org.my:8000/
>
>
>
>
>
> Thanks & have a blessing day!
>
>
>
>
>
> *Stay safe and alert to fight against Covid-19*
>
>
>
>
>
> *Best Regards,*
>
> *(Mdm.) Jesse Kah*
>
> *Lemonjar Software Media Sdn. Bhd.*
>
> -- Managing Director --
>
> *Mobile: *+6 (016) 8606 826
>
> *Tel:* +6 (03)7859 9226 (Selangor Office) | +6 (088) 713226 (Sabah office)
>
> *Fax:* +6 (088) 713226
>
> *Website:*  *https://www.lemonjar.com.my <https://www.lemonjar.com.my>*
>
>                   *https://www.edgetech.com.my
> <https://www.edgetech.com.my>*
>
>                 https://www.czur.my
>
> *Other Email:* lemonjarsm at gmail.com / lemonjar.sales at gmail.com
>
>
>
>
>
> *Lemonjar Facebook page:* https://www.facebook.com/lemonjarsoftmed/
>
> *Czur Facebook page: *https://www.facebook.com/CZURMalaysia
>
> *Edgetech Facebook page: *https://www.facebook.com/edgetechengineering/
>
> *YouTube page:*
> https://www.youtube.com/channel/UCLV34OjYVdG6KQK_uTC2f3A/featured
>
>
>
>
>
> Disclamer: Any reproduction, dissemination, copying, disclosure,
> modification, distribution and keeping of this message, without prior
> written consent of the sender are strictly prohibited.
>
>
>
> *Lemonjar Software Media Sdn. Bhd. *and *Edge Tech Engineering *Is
> specialising in manufacturing comprehensive solution in Library Automation
> Equipment Products – EM, RFID (HF/ UHF) and Hybrid solution; As well as
> having 12-years experiences in Open Source KOHA ILS System including
> customization and software development; as well as other Open Source system
> solutions specifically for Library.
>
>
>
> *Edge Tech Engineering *also specializes in the reselling, marketing and
> distribution of many prestigious and leading brands of ICT products,
> namely, HP, Acer, Dell, Asus, APC, Autodesk, Epson, Supermicro, Intel,
> Lenovo, Microsoft, Huawei, Symantec, Yes, Aruba, Cisco, Fujitsu, IBM,
> Intermec, Juniper, Oracle, Trend Micro, BitDefender, VMWare, Brother,
> Canon, Zebra Motorola and others.
>
>
>
> *Czur Malaysia* is Smart Scanner solutions range from Shine Series,
> Aurora Series, ET Series and M Series all come with auto OCR processing
> features.
>
>
>
>
>
>
>
> On 13/08/2021, 3:47 PM, "Koha on behalf of Koha Newsletter" <
> koha-bounces at lists.katipo.co.nz on behalf of kohanews at gmail.com> wrote:
>
>
>
>     Hi
>
>
>
>     I'm collecting news for the August 2021 Koha Community Newsletter.
>
>     Please send anything noteworthy to:
>
>
>
>     kohanews (at) gmail (dot) com
>
>
>
>     News criteria:
>
>     * News items can be of any length.
>
>     * Images are fine.
>
>     * Anything and everything Koha.
>
>     * Submit by the 26th of the month.
>
>
>
>     Text format criteria:
>
>     * Just structured plain text, or
>
>     * HTML text to include tables or similar
>
>
>
>     For events:
>
>     * Consider adding your event to the Koha Community calendar at
>
>     https://koha-community.org/calendar/
>
>
>
>     Thank you!
>
>
>
>     Michael Kuhn
>
>     Editor, Koha Community Newsletter
>
>     _______________________________________________
>
>
>
>     Koha mailing list  http://koha-community.org
>
>     Koha at lists.katipo.co.nz
>
>     Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20210817/eb7470d7/attachment.htm>

From jessekah at edgetech.com.my  Wed Aug 18 03:32:29 2021
From: jessekah at edgetech.com.my (JESSE KAH)
Date: Wed, 18 Aug 2021 09:32:29 +0800
Subject: [Koha-devel] [Koha] Call for news - Newsletter August 2021
In-Reply-To: <CAEqgz_nLzVwiNJT_nkTSGueXV=yu6ygeOpA2F+E8kBrOABBGcw@mail.gmail.com>
References: <CAEqgz_ni+SYSwYpsEKpXjBu0ZNnwT0C-FCVAa=wmcMR0TU4Tyg@mail.gmail.com>
 <992EBE5D-7F1C-41C4-B476-9A3845E9A17A@edgetech.com.my>
 <CAEqgz_nLzVwiNJT_nkTSGueXV=yu6ygeOpA2F+E8kBrOABBGcw@mail.gmail.com>
Message-ID: <7E4D48FF-5356-4410-B18C-0E25852EDCBD@edgetech.com.my>

Dear Michael,

 

Yes. The four libraries did goes live in the last 3-months.

I’ve update below in italic, with additional info on their architecture setup environment.

At the same time, I’ve also requested for login for the the update in https://wiki.koha-community.org/wiki/KohaUsers/SoutheastAsia.

 

Thanks for your check-up too. =)

 

1. The Federal Court of Malaysia

     Koha version 19.11 (bi-language: English and Bahasa Malaysia)

     Their OPAC is open for public to do searching via - https://libkoha.kehakiman.gov.my/ 

     However, login is only available for the staff of Federal Court of Malaysia via Active Directory login.

     Architecture setup in 3-tier environment.

     System goes live: mid-July 2021

 

2. The Attorney General of the state of Sabah, Malaysia

     Koha version 20.05

     Implemented version 16 during year 2018 and recently upgraded to version 20.05.

     Their searching in OPAC is ready only for internal Attorney General's access after login - https://sagclibrary.sabah.gov.my/ 

     Architecture setup in 2-tier environment.

     System goes live: mid-July 2021

 

3. Library of the Ministry of National Unity

    Koha version 20.05 (bi-language: English and Bahasa Malaysia)

Their OPAC is open for public to do searching via - http://pusatsumber.perpaduan.gov.my/.

Architecture setup in single-tier environment.

System goes live: early Aug 2021

 

4. Malaysia Institute of Architects (PAM)

    Koha version 18.11

    Implementation of Koha is done some times ago, however their OPAC is recently open for public access with re-designed new look.

    The searching in OPAC is closed and only available for registered architects to their organization, and self-registration is available via OPAC.

PAM OPAC can be access via: http://library.pam.org.my:8000/ 

Architecture setup in single-tier environment.

System goes live: early July 2021

 

 

 

Regards,

Jesse

Lemonjar Software Media Sdn. Bhd. (Malaysia)

 

 

From: Koha Newsletter <kohanews at gmail.com>
Date: Wednesday, 18 August 2021 at 5:53 AM
To: JESSE KAH <jessekah at edgetech.com.my>
Cc: oha <koha at lists.katipo.co.nz>, koha-devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha] Call for news - Newsletter August 2021

 

Hi Jesse

 

Thanks for your e-mail!

 

Did any of the mentioned four libraries go live in the last 1-3 months? If not then they do not qualify for the newsletter (which should contain news, of course). However, you could always add your implementations of Koha at https://wiki.koha-community.org/wiki/KohaUsers/SoutheastAsia

 

Best wishes: MIchael

 

On Mon, Aug 16, 2021 at 10:13 AM JESSE KAH <jessekah at edgetech.com.my> wrote:

Dear Michael,

 

Good day!

This is Jesse from Lemonjar Software Media Sdn. Bhd., Malaysia.

We have few implementation of Koha site in Malaysia and would like to share with the community as follow:

 

1. The Federal Court of Malaysia

     Koha version 19.11 (bi-language: English and Bahasa Malaysia)

     Their OPAC is open for public to do searching via - https://libkoha.kehakiman.gov.my/ 

     However, login is only available for the staff of Federal Court of Malaysia via Active Directory login.

 

2. The Attorney General of the state of Sabah, Malaysia

     Koha version 20.05 

     Their searching in OPAC is ready only for internal Attorney General's access after login - https://sagclibrary.sabah.gov.my/ 

 

3. Library of the Ministry of National Unity

    Koha version 20.05 (bi-language: English and Bahasa Malaysia)

    Their OPAC is open for public to do searching via - http://pusatsumber.perpaduan.gov.my/.

 

4. Malaysia Institute of Architects (PAM)

    Koha version 18.11

    Implementation of Koha is done some times ago, however their OPAC is recently open for public access with re-designed new look.

    The searching in OPAC is closed and only available for registered architects to their organization, and self-registration is available via OPAC.

    PAM OPAC can be access via: http://library.pam.org.my:8000/ 

 

 

Thanks & have a blessing day!

 

 

Stay safe and alert to fight against Covid-19

 

 

Best Regards,

(Mdm.) Jesse Kah

Lemonjar Software Media Sdn. Bhd.

-- Managing Director --

Mobile: +6 (016) 8606 826

Tel: +6 (03)7859 9226 (Selangor Office) | +6 (088) 713226 (Sabah office)

Fax: +6 (088) 713226

Website:  https://www.lemonjar.com.my  

                  https://www.edgetech.com.my 

                https://www.czur.my 

Other Email: lemonjarsm at gmail.com / lemonjar.sales at gmail.com 

 

 

Lemonjar Facebook page: https://www.facebook.com/lemonjarsoftmed/

Czur Facebook page: https://www.facebook.com/CZURMalaysia   

Edgetech Facebook page: https://www.facebook.com/edgetechengineering/ 

YouTube page: https://www.youtube.com/channel/UCLV34OjYVdG6KQK_uTC2f3A/featured 

 

 

Disclamer: Any reproduction, dissemination, copying, disclosure, modification, distribution and keeping of this message, without prior written consent of the sender are strictly prohibited.

 

Lemonjar Software Media Sdn. Bhd. and Edge Tech Engineering Is specialising in manufacturing comprehensive solution in Library Automation Equipment Products – EM, RFID (HF/ UHF) and Hybrid solution; As well as having 12-years experiences in Open Source KOHA ILS System including customization and software development; as well as other Open Source system solutions specifically for Library.

 

Edge Tech Engineering also specializes in the reselling, marketing and distribution of many prestigious and leading brands of ICT products, namely, HP, Acer, Dell, Asus, APC, Autodesk, Epson, Supermicro, Intel, Lenovo, Microsoft, Huawei, Symantec, Yes, Aruba, Cisco, Fujitsu, IBM, Intermec, Juniper, Oracle, Trend Micro, BitDefender, VMWare, Brother, Canon, Zebra Motorola and others.

 

Czur Malaysia is Smart Scanner solutions range from Shine Series, Aurora Series, ET Series and M Series all come with auto OCR processing features.

 

 

 

On 13/08/2021, 3:47 PM, "Koha on behalf of Koha Newsletter" <koha-bounces at lists.katipo.co.nz on behalf of kohanews at gmail.com> wrote:

 

    Hi

 

    I'm collecting news for the August 2021 Koha Community Newsletter.

    Please send anything noteworthy to:

 

    kohanews (at) gmail (dot) com

 

    News criteria:

    * News items can be of any length.

    * Images are fine.

    * Anything and everything Koha.

    * Submit by the 26th of the month.

 

    Text format criteria:

    * Just structured plain text, or

    * HTML text to include tables or similar

 

    For events:

    * Consider adding your event to the Koha Community calendar at

    https://koha-community.org/calendar/

 

    Thank you!

 

    Michael Kuhn

    Editor, Koha Community Newsletter

    _______________________________________________

 

    Koha mailing list  http://koha-community.org

    Koha at lists.katipo.co.nz

    Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

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

From dcook at prosentient.com.au  Wed Aug 18 03:36:43 2021
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Wed, 18 Aug 2021 11:36:43 +1000
Subject: [Koha-devel] Improvement of our upgrade process
In-Reply-To: <CAJzKNY7Jxrv=5hwnExU+Oh7TXjiFfPnjgHU+S4nKGajE5GP-4A@mail.gmail.com>
References: <CAJzKNY7Jxrv=5hwnExU+Oh7TXjiFfPnjgHU+S4nKGajE5GP-4A@mail.gmail.com>
Message-ID: <037e01d793d1$800d9260$8028b720$@prosentient.com.au>

Sounds good to me.

 

Is there a time when older versions will be taken out of updatedatabase.pl? At the moment, updatedatabase.pl is over 20,000 lines long. Maybe we could move the old entries into a 3to2105.pl script?

 

David Cook

Senior Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Jonathan Druart
Sent: Tuesday, 17 August 2021 7:17 PM
To: koha-devel <koha-devel at lists.koha-community.org>
Subject: [Koha-devel] Improvement of our upgrade process

 

Hi devs,

 

Bug 25078 was pushed yesterday and it modifies how we deal with our upgrade process.

 

I adjusted the wiki page - https://wiki.koha-community.org/wiki/Database_updates

 

The different things to know about it:

* The skeleton for atomic updates is modified [1]

* On push the atomic updates are no longer appended to updatedatabase.pl <http://updatedatabase.pl>  but moved to a new db_revs directory (named by version, like 210600016.pl <http://210600016.pl>  for the entry 21.06.00.016)

* Versions from 21.06.00.000 have been migrated to use this new mechanism, older are still in updatabase.pl <http://updatabase.pl> 

* updatabase.pl <http://updatabase.pl>  is still the script to call if you want to upgrade the DB

* Each DB rev (and atomic update) is executed in a transaction that rollbacks and stop the upgrade process if something went wrong

* Old atomicupdate format will still work (but require more work for the RM)

* Better error handling and better warnings possible

* Nicer UI during the upgrade step (step3)

 

Let me know if you have any questions!

 

Cheers,

Jonathan

 

[1] https://git.koha-community.org/Koha-community/Koha/src/commit/85c395460687f7e359417711b6facd42e0a24f8f/installer/data/mysql/atomicupdate/skeleton.pl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20210818/764e89b5/attachment.htm>

From wainuiwitikapark at catalyst.net.nz  Thu Aug 19 03:49:08 2021
From: wainuiwitikapark at catalyst.net.nz (Wainui Witika-Park)
Date: Thu, 19 Aug 2021 13:49:08 +1200
Subject: [Koha-devel] Time to translate: string freeze to prepare Koha
 19.11.21 has begun
Message-ID: <a14cb091-a331-9b2d-05ff-463677da385a@catalyst.net.nz>

Hello,

String freeze is into effect as of now for the 19.11.x maintenance
branch in preparation for the 19.11.21 release.

The minor release is scheduled for around the 23rd.

This means it's the right time to head over to the translation platform:
https://translate.koha-community.org/projects/

Reminder: if you add or change a translation in version 19.11, then you
must also copy it to 20.05, 20.11 and 21.05. Otherwise your work will be
lost for future versions.

Happy translating!

Wainui Witika-Park (she/her)

From dcook at prosentient.com.au  Thu Aug 19 05:12:41 2021
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Thu, 19 Aug 2021 13:12:41 +1000
Subject: [Koha-devel] Listing Zebra (and Elasticsearch) indexes for
 end-users' benefit
Message-ID: <045201d794a8$125fbe00$371f3a00$@prosentient.com.au>

Hi all,

 

As always, a new day brings a new Zebra idea.

 

One of my librarians asked me if there was any way to get a list of Zebra
indexes (particularly for Record Matching Rules), and I was all prepared to
say no. when I remembered something I read the other day. 

 

It turns out you can send the query "@attr exp1 1=1 attributedetails" to the
magical database "IR-explain-1", and it will give you a list of all the
indexes in that database along with the type of index and how many documents
are indexed against that index in the database. I think this is something
that we should add to Koha!

 

I'm not familiar with Koha's use of Elasticsearch, but I imagine there is an
easy way of getting a list of Elasticsearch indexes?

 

--

 

Of course, while having a list of indexes is good, it would be nice to know
what MARC data is in each of those indexes. I'm thinking about creating a
Koha Plugin that parses "biblio-koha-indexdefs.xml" and shows a
user-friendly view of what parts of the MARC record are put into which
indexes. 

 

--

 

What do folk think about that? I think having a list of Zebra indexes would
be very useful for Record Matching Rules, but also for a "Search tips" guide
for the Staff Interface and OPAC.

 

While we could provide a static list of indexes, but I think that would be
too much of a maintenance burden. I think having a list from Zebra (or
Elasticsearch), which we could cache in Memcached, would be the way to go. 

 

Ideally, we could have an API route that surfaces this information, so that
we could just do an AJAX lookup from a web interface. 

 

--

 

I'm hoping my librarian will sponsor development of a plugin, but I think
this would be useful in the core Koha code. 

 

David Cook

Senior Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20210819/398e3cd1/attachment.htm>

From pablo.bianchi at gmail.com  Thu Aug 19 08:31:28 2021
From: pablo.bianchi at gmail.com (Pablo Bianchi)
Date: Thu, 19 Aug 2021 03:31:28 -0300
Subject: [Koha-devel] Replacement of mailman (mailing lists)
In-Reply-To: <CAJzKNY4pkKQCoVhC_3h687X7tVhXb9p5hyUGrXiLZcKP_Ck6VQ@mail.gmail.com>
References: <CAJzKNY4pkKQCoVhC_3h687X7tVhXb9p5hyUGrXiLZcKP_Ck6VQ@mail.gmail.com>
Message-ID: <CAH2zftHcvQp7BCEcosDn8T_Mywa2rk+AWMpMoaHb=cDCo8vivg@mail.gmail.com>

Hi!

I created the Spanish community group back in 2008, recently moved to
mailman. I'd be more than happy if we move to something much more
modern/featureful/integratable and overall useful as Discourse (created by
Jeff Atwood (creator of Stack Overflow)). I believe this would give a major
boost to Koha communities.

Cheers,
Pablo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20210819/b4e27205/attachment.htm>

From dcook at prosentient.com.au  Thu Aug 19 08:42:01 2021
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Thu, 19 Aug 2021 16:42:01 +1000
Subject: [Koha-devel] Replacement of mailman (mailing lists)
In-Reply-To: <CAH2zftHcvQp7BCEcosDn8T_Mywa2rk+AWMpMoaHb=cDCo8vivg@mail.gmail.com>
References: <CAJzKNY4pkKQCoVhC_3h687X7tVhXb9p5hyUGrXiLZcKP_Ck6VQ@mail.gmail.com>
 <CAH2zftHcvQp7BCEcosDn8T_Mywa2rk+AWMpMoaHb=cDCo8vivg@mail.gmail.com>
Message-ID: <048601d794c5$509b4460$f1d1cd20$@prosentient.com.au>

It does seem like Discourse is reasonably popular although I’ve only engaged with it from the forum perspective. It looks like it does have mailing list support but I don’t know what that means exactly.

 

David Cook

Senior Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Pablo Bianchi
Sent: Thursday, 19 August 2021 4:31 PM
To: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Cc: koha-devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] Replacement of mailman (mailing lists)

 

Hi!

 

I created the Spanish community group back in 2008, recently moved to mailman. I'd be more than happy if we move to something much more modern/featureful/integratable and overall useful as Discourse (created by Jeff Atwood (creator of Stack Overflow)). I believe this would give a major boost to Koha communities.

 

Cheers,

Pablo

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20210819/284ff301/attachment.htm>

From fridolin.somers at biblibre.com  Thu Aug 19 09:03:02 2021
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Wed, 18 Aug 2021 21:03:02 -1000
Subject: [Koha-devel] systemd version of koha-plack-ctl.sh ?
In-Reply-To: <21e683ce-bdb3-cf2f-4b9c-e1d03b40b265@inlibro.com>
References: <21e683ce-bdb3-cf2f-4b9c-e1d03b40b265@inlibro.com>
Message-ID: <9ecf80cf-1fbd-b3aa-2b8e-fa9a5bf5ac46@biblibre.com>

Sure, we at Biblibre are using it since we use Nginx in Koha 16.11.

Here is our file.
We use dev install into /home/koha.

Where do you add timeout values ?$

Best regards,

Le 16/08/2021 à 11:17, Philippe Blouin a écrit :
> Hello all!
> 
> Has anyone been through the effort of coding a systemd unit file for 
> Koha's plack ?
> 
> I'm currently using an override.conf to specify some timeout values, and 
> that got me wondering (or wanting) about one.
> 
> Curiosity....
> 
> Thanks!
> 
> -- 
> Philippe Blouin,
> Directeur de la technologie
> 
> Tél.  : (833) 465-4276, poste 230
> philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>
> 
> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
> 

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
Software and system maintainer 🦄
BibLibre, France
-------------- next part --------------
A non-text attachment was scrubbed...
Name: starman.service
Type: text/x-dbus-service
Size: 849 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20210818/6eabe527/attachment-0001.bin>

From victor at tuxayo.net  Fri Aug 20 01:38:23 2021
From: victor at tuxayo.net (Victor Grousset/tuxayo)
Date: Fri, 20 Aug 2021 01:38:23 +0200
Subject: [Koha-devel] Improvement of our upgrade process
In-Reply-To: <CAJzKNY7Jxrv=5hwnExU+Oh7TXjiFfPnjgHU+S4nKGajE5GP-4A@mail.gmail.com>
References: <CAJzKNY7Jxrv=5hwnExU+Oh7TXjiFfPnjgHU+S4nKGajE5GP-4A@mail.gmail.com>
Message-ID: <a22c8f68-118d-b933-b9b5-ab3f27499719@tuxayo.net>

Hi :)

This is great news, thank for the summary.

On 21-08-17 11:16, Jonathan Druart wrote:
> Let me know if you have any questions!

I wonder how often
«say $out "Update is going well so far";»
will be left in submitted patches.
Let's try like that ^^


Cheers,

-- 
Victor Grousset/tuxayo

From victor at tuxayo.net  Fri Aug 20 01:47:41 2021
From: victor at tuxayo.net (Victor Grousset/tuxayo)
Date: Fri, 20 Aug 2021 01:47:41 +0200
Subject: [Koha-devel] Replacement of mailman (mailing lists)
In-Reply-To: <048601d794c5$509b4460$f1d1cd20$@prosentient.com.au>
References: <CAJzKNY4pkKQCoVhC_3h687X7tVhXb9p5hyUGrXiLZcKP_Ck6VQ@mail.gmail.com>
 <CAH2zftHcvQp7BCEcosDn8T_Mywa2rk+AWMpMoaHb=cDCo8vivg@mail.gmail.com>
 <048601d794c5$509b4460$f1d1cd20$@prosentient.com.au>
Message-ID: <920f2e4d-db2a-3c54-0ce3-80e01d00e848@tuxayo.net>

On 21-08-19 08:42, dcook at prosentient.com.au wrote:
> It does seem like Discourse is reasonably popular although I’ve only 
> engaged with it from the forum perspective. It looks like it does have 
> mailing list support but I don’t know what that means exactly.


https://meta.discourse.org/t/what-is-mailing-list-mode/46008
 > In mailing list mode you will receive one email per post, as happens 
with traditional mailing lists. This is desirable if you prefer to 
interact via email, without visiting the forum website.

https://meta.discourse.org/t/what-is-mailing-list-mode/46008/10
 > Yes, provided you configure “email reply support” appropriately


I just checked on an instance and it's possible to watch a category. It 
would have the same effect as subscribing to a mailing list.

---

Also, it's possible if it's worth the work to import a mailing list.
https://meta.discourse.org/t/discourse-vs-email-mailing-lists/54298/1

see
=> How do I import my mailing list?

=> My organisation manages multiple mailing lists. Can they be imported 
incrementally?



Cheers,

-- 
Victor Grousset/tuxayo

From mtj at kohaaloha.com  Wed Aug 25 07:59:59 2021
From: mtj at kohaaloha.com (Mason James)
Date: Wed, 25 Aug 2021 17:59:59 +1200
Subject: [Koha-devel] =?utf-8?q?Koha_packages_are_available_=F0=9F=8E=81?=
In-Reply-To: <9ABD9A39-E2A6-4912-ADC9-0160DDD13D12@gmail.com>
References: <9ABD9A39-E2A6-4912-ADC9-0160DDD13D12@gmail.com>
Message-ID: <f76d014b-0739-50eb-9f2c-54e6b9d5c27b@kohaaloha.com>

kia ora community,
the latest Koha packages are available

cheers, Mason

From victor at tuxayo.net  Wed Aug 25 08:19:55 2021
From: victor at tuxayo.net (Victor Grousset/tuxayo)
Date: Wed, 25 Aug 2021 08:19:55 +0200
Subject: [Koha-devel] =?utf-8?b?S29oYSAyMC4wNS4xNSByZWxlYXNlZCwg4pqgIHNl?=
 =?utf-8?q?curity_release?=
Message-ID: <6f1ffc29-54de-f656-1253-3ff2b06c1f3f@tuxayo.net>

Hello! :)

The Koha Community is happy to announce the release of Koha 20.05.15

The full release notes can be found at:
https://koha-community.org/koha-20-05-15-released/

The Debian packages are already available.

Thanks to everyone involved :)


Cheers,

-- 
Victor Grousset/tuxayo

From fridolin.somers at biblibre.com  Wed Aug 25 08:50:24 2021
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Tue, 24 Aug 2021 20:50:24 -1000
Subject: [Koha-devel] Release of Koha 20.11.09
Message-ID: <33195afb-94d2-b089-d033-c50b5af7c39e@biblibre.com>

Hi everyone 🤗

The Koha community is proud to announce the release of Koha 20.11.09 🚀

It is a maintenance release with 1 security fix 🛠️

The full release notes are available here 📜
https://koha-community.org/koha-20-11-09-released/

The Debian packages are already available 🌼

Best regards 🌊

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
Software and system maintainer 🦄
BibLibre, France

From mik at adminkuhn.ch  Wed Aug 25 22:53:18 2021
From: mik at adminkuhn.ch (Michael Kuhn)
Date: Wed, 25 Aug 2021 22:53:18 +0200
Subject: [Koha-devel] Character sets in MariaDB 10.5
Message-ID: <0011807a-5ea6-cbed-6c9c-81e92f7cb9da@adminkuhn.ch>

Hi

1. In the last few years when installing Koha on Debian GNU/Linux 9 or 
10 the character sets in MariaDB were as follows:

MariaDB [(none)]> SHOW VARIABLES LIKE '%char%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8mb4                    |
| character_set_connection | utf8mb4                    |
| character_set_database   | utf8mb4                    |
| character_set_filesystem | binary                     |
| character_set_results    | utf8mb4                    |
| character_set_server     | utf8mb4                    |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+

Today I installed Koha 21.05.03 on Debian GNU/Linux 11 with MariaDB 
10.5.11 where the character sets are as follows:

MariaDB [(none)]> SHOW VARIABLES LIKE '%char%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | utf8mb4                    |
| character_set_filesystem | binary                     |
| character_set_results    | utf8                       |
| character_set_server     | utf8mb4                    |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+

I'm not sure what is going on here. Does anyone know why the character 
sets for client, connection and results have changed from utf8mb4 to 
utf8? Is this correct with Koha or should these character sets be changed?

2. Today I came upon an installation of Koha 18.11.05 using MariaDB 
10.0.32 which has the following character sets:

MariaDB [(none)]> SHOW VARIABLES LIKE '%char%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | latin1                     |
| character_set_filesystem | binary                     |
| character_set_results    | utf8                       |
| character_set_server     | latin1                     |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+

This seems quite wrong to me - as far as I know "latin1" was never a 
supported character set in Koha... as far as I know the character sets 
should be set as shown in topic 1.

However, is it still possible to update such a database with these 
character sets to Koha 21.05.03 without destroying the data completely?

Best wishes: Michael
-- 
Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
T 0041 (0)61 261 55 61 · E mik at adminkuhn.ch · W www.adminkuhn.ch

From tomascohen at gmail.com  Thu Aug 26 01:03:39 2021
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Wed, 25 Aug 2021 20:03:39 -0300
Subject: [Koha-devel] Character sets in MariaDB 10.5
In-Reply-To: <0011807a-5ea6-cbed-6c9c-81e92f7cb9da@adminkuhn.ch>
References: <0011807a-5ea6-cbed-6c9c-81e92f7cb9da@adminkuhn.ch>
Message-ID: <CABZfb=VXsRxp0eCV_tFhnJSraCW26bkYGkZ8vgQk4FmD4ncx5g@mail.gmail.com>

Those are just defaults in the OS distribution, that can be changed at will.

Koha, internally, sets the character set correctly on connection time [1].

You should always check when they drop support for our used encodings.
Which is not the case (for now?). We have the test suite run against the
latest versions of MariaDB for that purpose.

I recommend you set that defaults correctly so they are picked when you use
the CLI.

Best regards

[1]
https://git.koha-community.org/Koha-community/Koha/src/branch/master/Koha/Database.pm#L74

El mié., 25 ago. 2021 17:54, Michael Kuhn <mik at adminkuhn.ch> escribió:

> Hi
>
> 1. In the last few years when installing Koha on Debian GNU/Linux 9 or
> 10 the character sets in MariaDB were as follows:
>
> MariaDB [(none)]> SHOW VARIABLES LIKE '%char%';
> +--------------------------+----------------------------+
> | Variable_name            | Value                      |
> +--------------------------+----------------------------+
> | character_set_client     | utf8mb4                    |
> | character_set_connection | utf8mb4                    |
> | character_set_database   | utf8mb4                    |
> | character_set_filesystem | binary                     |
> | character_set_results    | utf8mb4                    |
> | character_set_server     | utf8mb4                    |
> | character_set_system     | utf8                       |
> | character_sets_dir       | /usr/share/mysql/charsets/ |
> +--------------------------+----------------------------+
>
> Today I installed Koha 21.05.03 on Debian GNU/Linux 11 with MariaDB
> 10.5.11 where the character sets are as follows:
>
> MariaDB [(none)]> SHOW VARIABLES LIKE '%char%';
> +--------------------------+----------------------------+
> | Variable_name            | Value                      |
> +--------------------------+----------------------------+
> | character_set_client     | utf8                       |
> | character_set_connection | utf8                       |
> | character_set_database   | utf8mb4                    |
> | character_set_filesystem | binary                     |
> | character_set_results    | utf8                       |
> | character_set_server     | utf8mb4                    |
> | character_set_system     | utf8                       |
> | character_sets_dir       | /usr/share/mysql/charsets/ |
> +--------------------------+----------------------------+
>
> I'm not sure what is going on here. Does anyone know why the character
> sets for client, connection and results have changed from utf8mb4 to
> utf8? Is this correct with Koha or should these character sets be changed?
>
> 2. Today I came upon an installation of Koha 18.11.05 using MariaDB
> 10.0.32 which has the following character sets:
>
> MariaDB [(none)]> SHOW VARIABLES LIKE '%char%';
> +--------------------------+----------------------------+
> | Variable_name            | Value                      |
> +--------------------------+----------------------------+
> | character_set_client     | utf8                       |
> | character_set_connection | utf8                       |
> | character_set_database   | latin1                     |
> | character_set_filesystem | binary                     |
> | character_set_results    | utf8                       |
> | character_set_server     | latin1                     |
> | character_set_system     | utf8                       |
> | character_sets_dir       | /usr/share/mysql/charsets/ |
> +--------------------------+----------------------------+
>
> This seems quite wrong to me - as far as I know "latin1" was never a
> supported character set in Koha... as far as I know the character sets
> should be set as shown in topic 1.
>
> However, is it still possible to update such a database with these
> character sets to Koha 21.05.03 without destroying the data completely?
>
> Best wishes: Michael
> --
> Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
> Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
> T 0041 (0)61 261 55 61 · E mik at adminkuhn.ch · W www.adminkuhn.ch
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : https://www.koha-community.org/
> git : https://git.koha-community.org/
> bugs : https://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20210825/b00def01/attachment.htm>

From wainuiwitikapark at catalyst.net.nz  Thu Aug 26 03:42:46 2021
From: wainuiwitikapark at catalyst.net.nz (Wainui Witika-Park)
Date: Thu, 26 Aug 2021 13:42:46 +1200
Subject: [Koha-devel] Koha 19.11.21 released
Message-ID: <91f4eecb-b083-cd23-859b-a49167b19dd2@catalyst.net.nz>

Hello everyone!

The Koha community is proud to announce the release of version 19.11.21.

The full release notes can be found at:
https://koha-community.org/koha-19-11-21-released/

Thank you to everyone involved!

Cheers,

Wainui Witika-Park (she/her)

From mik at adminkuhn.ch  Thu Aug 26 14:31:48 2021
From: mik at adminkuhn.ch (Michael Kuhn)
Date: Thu, 26 Aug 2021 14:31:48 +0200
Subject: [Koha-devel] Character sets in MariaDB 10.5
In-Reply-To: <CABZfb=VXsRxp0eCV_tFhnJSraCW26bkYGkZ8vgQk4FmD4ncx5g@mail.gmail.com>
References: <0011807a-5ea6-cbed-6c9c-81e92f7cb9da@adminkuhn.ch>
 <CABZfb=VXsRxp0eCV_tFhnJSraCW26bkYGkZ8vgQk4FmD4ncx5g@mail.gmail.com>
Message-ID: <04cc99a7-dfaa-10ec-bb4e-6cb0fd7ea10e@adminkuhn.ch>

Hi Tomas

Today you wrote:

 > Those are just defaults in the OS distribution, that can be changed at
 > will.
 >
 > Koha, internally, sets the character set correctly on connection time
 > [1].
 >
 > You should always check when they drop support for our used encodings.
 > Which is not the case (for now?). We have the test suite run against
 > the latest versions of MariaDB for that purpose.
 >
 > I recommend you set that defaults correctly so they are picked when
 > you use the CLI.

I have now added the following line in both files 
"/etc/mysql/mariadb.conf.d/50-client.cnf" /section [client]) and 
"/etc/mysql/mariadb.conf.d/50-mysql-clients.cnf" (section [mysql]):

default-character-set = utf8mb4

Now as in Debian 9 and 10 the character sets in MariaDB running on 
Debian 11 look as follows:

MariaDB [(none)]> SHOW VARIABLES LIKE 'character_set_%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8mb4                    |
| character_set_connection | utf8mb4                    |
| character_set_database   | utf8mb4                    |
| character_set_filesystem | binary                     |
| character_set_results    | utf8mb4                    |
| character_set_server     | utf8mb4                    |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+

Thank you very much for your recommendation!

Best wishes: Michael
-- 
Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
T 0041 (0)61 261 55 61 · E mik at adminkuhn.ch · W www.adminkuhn.ch




> El mié., 25 ago. 2021 17:54, Michael Kuhn <mik at adminkuhn.ch 
> <mailto:mik at adminkuhn.ch>> escribió:
> 
>     Hi
> 
>     1. In the last few years when installing Koha on Debian GNU/Linux 9 or
>     10 the character sets in MariaDB were as follows:
> 
>     MariaDB [(none)]> SHOW VARIABLES LIKE '%char%';
>     +--------------------------+----------------------------+
>     | Variable_name            | Value                      |
>     +--------------------------+----------------------------+
>     | character_set_client     | utf8mb4                    |
>     | character_set_connection | utf8mb4                    |
>     | character_set_database   | utf8mb4                    |
>     | character_set_filesystem | binary                     |
>     | character_set_results    | utf8mb4                    |
>     | character_set_server     | utf8mb4                    |
>     | character_set_system     | utf8                       |
>     | character_sets_dir       | /usr/share/mysql/charsets/ |
>     +--------------------------+----------------------------+
> 
>     Today I installed Koha 21.05.03 on Debian GNU/Linux 11 with MariaDB
>     10.5.11 where the character sets are as follows:
> 
>     MariaDB [(none)]> SHOW VARIABLES LIKE '%char%';
>     +--------------------------+----------------------------+
>     | Variable_name            | Value                      |
>     +--------------------------+----------------------------+
>     | character_set_client     | utf8                       |
>     | character_set_connection | utf8                       |
>     | character_set_database   | utf8mb4                    |
>     | character_set_filesystem | binary                     |
>     | character_set_results    | utf8                       |
>     | character_set_server     | utf8mb4                    |
>     | character_set_system     | utf8                       |
>     | character_sets_dir       | /usr/share/mysql/charsets/ |
>     +--------------------------+----------------------------+
> 
>     I'm not sure what is going on here. Does anyone know why the character
>     sets for client, connection and results have changed from utf8mb4 to
>     utf8? Is this correct with Koha or should these character sets be
>     changed?
> 
>     2. Today I came upon an installation of Koha 18.11.05 using MariaDB
>     10.0.32 which has the following character sets:
> 
>     MariaDB [(none)]> SHOW VARIABLES LIKE '%char%';
>     +--------------------------+----------------------------+
>     | Variable_name            | Value                      |
>     +--------------------------+----------------------------+
>     | character_set_client     | utf8                       |
>     | character_set_connection | utf8                       |
>     | character_set_database   | latin1                     |
>     | character_set_filesystem | binary                     |
>     | character_set_results    | utf8                       |
>     | character_set_server     | latin1                     |
>     | character_set_system     | utf8                       |
>     | character_sets_dir       | /usr/share/mysql/charsets/ |
>     +--------------------------+----------------------------+
> 
>     This seems quite wrong to me - as far as I know "latin1" was never a
>     supported character set in Koha... as far as I know the character sets
>     should be set as shown in topic 1.
> 
>     However, is it still possible to update such a database with these
>     character sets to Koha 21.05.03 without destroying the data completely?
> 
>     Best wishes: Michael
>     -- 
>     Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
>     Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
>     T 0041 (0)61 261 55 61 · E mik at adminkuhn.ch
>     <mailto:mik at adminkuhn.ch> · W www.adminkuhn.ch <http://www.adminkuhn.ch>
>     _______________________________________________
>     Koha-devel mailing list
>     Koha-devel at lists.koha-community.org
>     <mailto:Koha-devel at 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/>
> 



From mik at adminkuhn.ch  Thu Aug 26 15:50:34 2021
From: mik at adminkuhn.ch (Michael Kuhn)
Date: Thu, 26 Aug 2021 15:50:34 +0200
Subject: [Koha-devel] Installing Koha 21.05.03-1 but Koha gives 21.05.02.003
 as the installed version
Message-ID: <f86d8da3-3e30-95fe-503e-3a0d45c7410c@adminkuhn.ch>

Hi

Yesterday/today I was installing the most current Koha:

$ sudo apt-cache show koha-common | grep Version
Version: 21.05.03-1

During the installation of Debian package "koha-common" it says:

Holen:62 http://debian.koha-community.org/koha 21.05/main amd64 
koha-common all 21.05.03-1 [41,1 MB]
...
Vorbereitung zum Entpacken von .../485-koha-common_21.05.03-1_all.deb ...
Entpacken von koha-common (21.05.03-1) ...
...
koha-common (21.05.03-1) wird eingerichtet ...


But after the installation I see the following in Koha menu "About Koha":

Koha version: 	21.05.02.003

Also in the source text of the OPAC main page it says:

<meta name="generator" content="Koha 21.0502003" />


This happened on a completely new machine with Debian GNU Linux 11.0.

Best wishes: Michael
-- 
Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
T 0041 (0)61 261 55 61 · E mik at adminkuhn.ch · W www.adminkuhn.ch

From jonathan.druart at bugs.koha-community.org  Thu Aug 26 16:17:25 2021
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Thu, 26 Aug 2021 16:17:25 +0200
Subject: [Koha-devel] Installing Koha 21.05.03-1 but Koha gives
 21.05.02.003 as the installed version
In-Reply-To: <f86d8da3-3e30-95fe-503e-3a0d45c7410c@adminkuhn.ch>
References: <f86d8da3-3e30-95fe-503e-3a0d45c7410c@adminkuhn.ch>
Message-ID: <CAJzKNY44OHWHG-VhJ0gZ5YXFrayeSkk3P4HU-qv3ee9EfGS+Cw@mail.gmail.com>

Indeed, it's coming from

commit 8ea80995c590dad86c43df636456640d3aa84bab
    Increment version for 21.05.03 release

-$VERSION = "21.05.02.002";
+$VERSION = "21.05.02.003";

Le jeu. 26 août 2021 à 15:50, Michael Kuhn <mik at adminkuhn.ch> a écrit :
>
> Hi
>
> Yesterday/today I was installing the most current Koha:
>
> $ sudo apt-cache show koha-common | grep Version
> Version: 21.05.03-1
>
> During the installation of Debian package "koha-common" it says:
>
> Holen:62 http://debian.koha-community.org/koha 21.05/main amd64
> koha-common all 21.05.03-1 [41,1 MB]
> ...
> Vorbereitung zum Entpacken von .../485-koha-common_21.05.03-1_all.deb ...
> Entpacken von koha-common (21.05.03-1) ...
> ...
> koha-common (21.05.03-1) wird eingerichtet ...
>
>
> But after the installation I see the following in Koha menu "About Koha":
>
> Koha version:   21.05.02.003
>
> Also in the source text of the OPAC main page it says:
>
> <meta name="generator" content="Koha 21.0502003" />
>
>
> This happened on a completely new machine with Debian GNU Linux 11.0.
>
> Best wishes: Michael
> --
> Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
> Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
> T 0041 (0)61 261 55 61 · E mik at adminkuhn.ch · W www.adminkuhn.ch
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

From kohanews at gmail.com  Fri Aug 27 17:59:37 2021
From: kohanews at gmail.com (Koha Newsletter)
Date: Fri, 27 Aug 2021 17:59:37 +0200
Subject: [Koha-devel] Koha Community Newsletter: August 2021
Message-ID: <CAEqgz_=1b0-PSQp2oypKZvPhYs1mQPHju93OBHaOfnYmRbcyzw@mail.gmail.com>

The Koha Community Newsletter for August 2021 is here:

* https://koha-community.org/koha-community-newsletter-august-2021/

Many thanks to everyone who submitted articles and news this newsletter!

Please feel free to email me with any corrections or suggestions.
--
Michael Kuhn
Editor, Koha Community Newsletter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20210827/1ff47f9f/attachment.htm>

From victor at tuxayo.net  Sat Aug 28 09:38:04 2021
From: victor at tuxayo.net (Victor Grousset/tuxayo)
Date: Sat, 28 Aug 2021 09:38:04 +0200
Subject: [Koha-devel] Perl advice for checking hash content
Message-ID: <4aeca8ca-6b49-d8a6-35ee-8829e68d41b2@tuxayo.net>

Hi :)

For a development, I'm adding additional keys to 
C4::Reserves::CanItemBeReserved returned hash.

But there are a bunch of tests that match the whole return value and 
thus don't expect the new keys in the hash.

Here is the best way so far I've found to adapt it.


is_deeply(
     CanItemBeReserved( $patron->borrowernumber, $itemnumber_2 ),
     { status => 'tooManyReservesToday', limit => 0 },
     'Patron cannot reserve if holds_per_day is 0 (i.e. 0 is 0)'
);

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

my @status_and_limit = @{CanItemBeReserved( $patron->borrowernumber, 
$itemnumber_2 )}{"status", "limit"};
is_deeply(
     \@status_and_limit,
     ['tooManyReservesToday', 0],
     'Patron cannot reserve if holds_per_day is 0 (i.e. 0 is 0)'
);


How could this be better?
Since it took me more than two hours only to have something that works 
and without warnings. There are surely other ways to do it™, and 
hopefully a nicer one.
Most of the time was reading and learning by trial and error about 
referencing and dereferencing and the specifics or Perl hashes and 
array. It's odd to have been working 3.5 years on Koha closer to the 
code than to the librarian stuff and only have to really start learning 
Perl now ^^
Away, this is why advice is needed to have something that fit the good 
practices :)

Key/Value Hash Slices would allow to not change the expected param of 
is_deeply() but that doesn't really look different for the readability.
And isn't worth having Koha bump minimal Perl version from 5.14 (2011) 
to 5.20 (2014). Ok it's just for running the tests and not production 
but still. -> very minor or inexistent readability improvement.
https://perldoc.perl.org/perldata#Key/Value-Hash-Slices

Having two assertions (is() calls) for status and limit would allow a 
simpler syntax but add duplication.


Cheers,

-- 
Victor Grousset/tuxayo

From jonathan.druart at bugs.koha-community.org  Mon Aug 30 11:07:56 2021
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Mon, 30 Aug 2021 11:07:56 +0200
Subject: [Koha-devel] Perl advice for checking hash content
In-Reply-To: <4aeca8ca-6b49-d8a6-35ee-8829e68d41b2@tuxayo.net>
References: <4aeca8ca-6b49-d8a6-35ee-8829e68d41b2@tuxayo.net>
Message-ID: <CAJzKNY4z_mwSc2bGgq6Sa55hUujd02BrtV65RHwn-XGoLqV0Pg@mail.gmail.com>

Keep it simple, why not the following?

my $canbe = CanItemBeReserved( $patron->borrowernumber, $itemnumber );
is_deeply(
     [$canbe->{status}, $canbe->{limit}]
     ['tooManyReservesToday', 0],
     'Patron cannot reserve if holds_per_day is 0 (i.e. 0 is 0)'
);

Le sam. 28 août 2021 à 09:38, Victor Grousset/tuxayo
<victor at tuxayo.net> a écrit :
>
> Hi :)
>
> For a development, I'm adding additional keys to
> C4::Reserves::CanItemBeReserved returned hash.
>
> But there are a bunch of tests that match the whole return value and
> thus don't expect the new keys in the hash.
>
> Here is the best way so far I've found to adapt it.
>
>
> is_deeply(
>      CanItemBeReserved( $patron->borrowernumber, $itemnumber_2 ),
>      { status => 'tooManyReservesToday', limit => 0 },
>      'Patron cannot reserve if holds_per_day is 0 (i.e. 0 is 0)'
> );
>
> ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
>
> my @status_and_limit = @{CanItemBeReserved( $patron->borrowernumber,
> $itemnumber_2 )}{"status", "limit"};
> is_deeply(
>      \@status_and_limit,
>      ['tooManyReservesToday', 0],
>      'Patron cannot reserve if holds_per_day is 0 (i.e. 0 is 0)'
> );
>
>
> How could this be better?
> Since it took me more than two hours only to have something that works
> and without warnings. There are surely other ways to do it™, and
> hopefully a nicer one.
> Most of the time was reading and learning by trial and error about
> referencing and dereferencing and the specifics or Perl hashes and
> array. It's odd to have been working 3.5 years on Koha closer to the
> code than to the librarian stuff and only have to really start learning
> Perl now ^^
> Away, this is why advice is needed to have something that fit the good
> practices :)
>
> Key/Value Hash Slices would allow to not change the expected param of
> is_deeply() but that doesn't really look different for the readability.
> And isn't worth having Koha bump minimal Perl version from 5.14 (2011)
> to 5.20 (2014). Ok it's just for running the tests and not production
> but still. -> very minor or inexistent readability improvement.
> https://perldoc.perl.org/perldata#Key/Value-Hash-Slices
>
> Having two assertions (is() calls) for status and limit would allow a
> simpler syntax but add duplication.
>
>
> Cheers,
>
> --
> Victor Grousset/tuxayo
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

From victor at tuxayo.net  Mon Aug 30 21:52:54 2021
From: victor at tuxayo.net (Victor Grousset/tuxayo)
Date: Mon, 30 Aug 2021 21:52:54 +0200
Subject: [Koha-devel] Perl advice for checking hash content
In-Reply-To: <CAJzKNY4z_mwSc2bGgq6Sa55hUujd02BrtV65RHwn-XGoLqV0Pg@mail.gmail.com>
References: <4aeca8ca-6b49-d8a6-35ee-8829e68d41b2@tuxayo.net>
 <CAJzKNY4z_mwSc2bGgq6Sa55hUujd02BrtV65RHwn-XGoLqV0Pg@mail.gmail.com>
Message-ID: <95def8b3-bc24-1ed9-2eea-62c88975393f@tuxayo.net>

On 21-08-30 11:07, Jonathan Druart wrote:
> Keep it simple, why not the following?

Because I didn't think of it :O
Thanks a lot, tests fixed!

Cheers,

-- 
Victor Grousset/tuxayo

From oleonard at myacpl.org  Tue Aug 31 23:51:10 2021
From: oleonard at myacpl.org (Owen Leonard)
Date: Tue, 31 Aug 2021 17:51:10 -0400
Subject: [Koha-devel] Built-in offline circulation interface
Message-ID: <CAO4qe2MCn92PTug24TW8yyhU9hZ3WL8dPfQorru+WMH2sYkngg@mail.gmail.com>

Does anyone use it? The one enabled by the AllowOfflineCirculation
system preference. I don't think the core functionality of the feature
has been touched since its original introduction and I'm concerned
that it either doesn't work or is too fragile to be used in
production.

I'm not asking because I'm thinking of using it but because I'm
concerned about us promising users that it works.

Thanks,

   Owen

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