From mtj at kohaaloha.com  Fri Apr  1 04:07:48 2022
From: mtj at kohaaloha.com (Mason James)
Date: Fri, 1 Apr 2022 15:07:48 +1300
Subject: [Koha-devel] =?utf-8?q?Koha_releases_are_available_=F0=9F=8E=81?=
In-Reply-To: <136fee14-3afd-7e69-6a30-d2e586bb6b93@kohaaloha.com>
References: <136fee14-3afd-7e69-6a30-d2e586bb6b93@kohaaloha.com>
Message-ID: <25b5b960-b3a0-34b4-d0ee-597f1f4bc7c0@kohaaloha.com>

kia ora community,

the latest Koha packages are available

installation guide is below...
  https://wiki.koha-community.org/wiki/Koha_on_Debian


cheers, Mason

From ztajoli at gmail.com  Sat Apr  2 12:51:05 2022
From: ztajoli at gmail.com (Zeno Tajoli)
Date: Sat, 2 Apr 2022 12:51:05 +0200
Subject: [Koha-devel] Need help to test a patch that will simplify
 translations
In-Reply-To: <7c239738-2076-8e1f-d7e9-8be477b66e66@tuxayo.net>
References: <7c239738-2076-8e1f-d7e9-8be477b66e66@tuxayo.net>
Message-ID: <CACwhcG1CehY2jmz7Ce=OU2LXkGbYNgm4xJQnRAn2+QRm-TLb-w@mail.gmail.com>

Hi to all,
I try to test the patches with .bywater sandboxes, but they don't apply.
In provision log I read:

TASK [Apply bug 29602 via git-bz in docker container] **************************
fatal: [localhost -> koha-nicetrad]: FAILED! => {"changed": true,

"cmd": "cd /kohadevbox/koha && yes | git bz apply 29602", "delta":
"0:00:06.139954", "end": "2022-04-02 10:00:04.110333",

"msg": "non-zero return code", "rc": 1, "start": "2022-04-02 09:59:57.970379",

"stderr": "Traceback (most recent call last):\n  File
\"/usr/bin/git-bz\", line 2716, in <module>\n    applied =
do_apply(bug_ref)\n  File \"/usr/bin/git-bz\", line 1791, in
do_apply\n    print \"%d - %s\" % (patch.attach_id,
patch.description)\nUnicodeEncodeError: 'ascii' codec can't encode
character u'\\u2192' in position 56: ordinal not in range(128)",

"stderr_lines": ["Traceback (most recent call last):", "  File
\"/usr/bin/git-bz\", line 2716, in <module>", "    applied =
do_apply(bug_ref)", "  File \"/usr/bin/git-bz\", line 1791, in
do_apply", "    print \"%d - %s\" % (patch.attach_id,
patch.description)", "UnicodeEncodeError: 'ascii' codec can't encode
character u'\\u2192' in position 56: ordinal not in range(128)"],

"stdout": "\nBug 29602 - We must be nicer with translators",
"stdout_lines": ["", "Bug 29602 - We must be nicer with translators"]}

I'm not sure those are patches for sandboxes, but in fact they have at
least an error about Unicode.
The sandbox is here: https://sandbox.bywatersolutions.com/, name 'nicetrad'
Cheers
Zeno Tajoli



On Sat, Mar 19, 2022 at 5:23 PM Victor Grousset/tuxayo <victor at tuxayo.net>
wrote:

> Hi,
>
> After a few iterations of testing and fixes, bug 29602 looks about
> ready. It mostly needs someone else to signoff by testing that pages are
> not broken.
> Here is a ticket with a link to the comment listing most of the impacted
> pages:
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29602#c50
> Rereading the last follow-up patches would also help.
>
> Let me know if I can be of any help.
>
> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220402/42c7fef6/attachment.htm>

From jonathan.druart at bugs.koha-community.org  Fri Apr  8 09:43:41 2022
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Fri, 8 Apr 2022 09:43:41 +0200
Subject: [Koha-devel] Vote on Vue3 (for ERM) at the next dev meeting
Message-ID: <CAJzKNY51pBigUE8A8z2gA9r-GBAePJoZObk1xBmQKfWcuq3bTg@mail.gmail.com>

Hi devs,

Could we vote at the next dev meeting that the ERM module will be
written in Vue3 and that it will not be a problem for its integration
into Koha?

This module will contain a lot of CRUD operations and simple forms.
And so all the necessary REST API routes will be provided from the
beginning.
I thought it would be a good candidate to introduce a new and modern
solution to Koha.
Using it in an isolated module will allow us to try it, find the
different problems we can face, fix them, and not force other
developers to be onboard if they don't want to.

There is already a POC of this module using Vue3, with the different
REST API routes, and UI testing using Cypress (see link below).

Other solutions are:
* Use another JS framework (but in that case you will show us on the
"cities" view a simple implementation case)
* Use the old/traditional way

Links related to ERM and Vue3:
* Electronic Resource Management for Koha
https://lists.katipo.co.nz/pipermail/koha/2022-February/057447.html
* Sandbox - https://staff-erm.sandboxes.biblibre.eu/cgi-bin/koha/erm/agreements.pl
* Git remote branch - https://gitlab.com/joubu/Koha/-/commits/erm
* Cities rewrites
** Bug 30160 - Rewrite cities admin view in React
** Bug 30225 - Rewrite cities admin view in Vue
** "I played with React"
https://lists.koha-community.org/pipermail/koha-devel/2022-February/046926.html
* "I played with Cypress (and ERM and Vue)"
https://lists.koha-community.org/pipermail/koha-devel/2022-March/046956.html

Cheers,
Jonathan

From dcook at prosentient.com.au  Mon Apr 11 02:58:28 2022
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Mon, 11 Apr 2022 10:58:28 +1000
Subject: [Koha-devel] Vote on Vue3 (for ERM) at the next dev meeting
In-Reply-To: <CAJzKNY51pBigUE8A8z2gA9r-GBAePJoZObk1xBmQKfWcuq3bTg@mail.gmail.com>
References: <CAJzKNY51pBigUE8A8z2gA9r-GBAePJoZObk1xBmQKfWcuq3bTg@mail.gmail.com>
Message-ID: <025d01d84d3f$447d4b50$cd77e1f0$@prosentient.com.au>

Voting on it at the next dev meeting sounds like a good idea, and I think that all your points are reasonable. I probably won't be at the dev meeting, but +1 for moving ahead with Vue3 for the ERM module. (I wonder if we should have pre-polls/mail-in votes for dev meetings sometimes...)

I think that my only concern is with the current implementation. As I note at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30225#c13, I think we should be using more generic CRUD components and then inheriting from those. However, that's arguably a naïve comment, since I don't have much experience with Vue3 myself (beyond reading and 1 hello world exercise). That said, I would guess that all of us are inexperienced with Vue3 though, so that might pose some QA difficulties... 

Actually, I notice in https://lists.katipo.co.nz/pipermail/koha/2022-February/057447.html that it mentions that a team of people from Bywater, BibLibre, and PTFS Europe are supporting the eRM project. Are they gaining experience with Vue3 as well? 

I would be interested in getting more involved with this project as a Vue3 project in terms of development and QA. I'll email Jonathan Fielding more about that.

Here's hoping a majority agree about moving forward with the ERM module being written in Vue3. 

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 Jonathan Druart
Sent: Friday, 8 April 2022 5:44 PM
To: koha-devel <koha-devel at lists.koha-community.org>
Subject: [Koha-devel] Vote on Vue3 (for ERM) at the next dev meeting

Hi devs,

Could we vote at the next dev meeting that the ERM module will be written in Vue3 and that it will not be a problem for its integration into Koha?

This module will contain a lot of CRUD operations and simple forms.
And so all the necessary REST API routes will be provided from the beginning.
I thought it would be a good candidate to introduce a new and modern solution to Koha.
Using it in an isolated module will allow us to try it, find the different problems we can face, fix them, and not force other developers to be onboard if they don't want to.

There is already a POC of this module using Vue3, with the different REST API routes, and UI testing using Cypress (see link below).

Other solutions are:
* Use another JS framework (but in that case you will show us on the "cities" view a simple implementation case)
* Use the old/traditional way

Links related to ERM and Vue3:
* Electronic Resource Management for Koha https://lists.katipo.co.nz/pipermail/koha/2022-February/057447.html
* Sandbox - https://staff-erm.sandboxes.biblibre.eu/cgi-bin/koha/erm/agreements.pl
* Git remote branch - https://gitlab.com/joubu/Koha/-/commits/erm
* Cities rewrites
** Bug 30160 - Rewrite cities admin view in React
** Bug 30225 - Rewrite cities admin view in Vue
** "I played with React"
https://lists.koha-community.org/pipermail/koha-devel/2022-February/046926.html
* "I played with Cypress (and ERM and Vue)"
https://lists.koha-community.org/pipermail/koha-devel/2022-March/046956.html

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


From fridolin.somers at biblibre.com  Tue Apr 12 11:13:41 2022
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Tue, 12 Apr 2022 11:13:41 +0200
Subject: [Koha-devel] Roles for 22.11 open
Message-ID: <4515e8f2-3d7a-3731-e78f-1044d96434f8@biblibre.com>

Hi dear community.

22.05 cycle comes to an end, time to think of next cycle.

The roles for the 22.11 release cycle are now opened :
https://wiki.koha-community.org/wiki/Roles_for_22.11

The vote will take place during next general IRC meeting on May 4th.

The description of the roles can be found at this wiki page :
https://wiki.koha-community.org/wiki/Project_roles

<< Join us in the dark side, we have cookies >>

Best regards,

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

From fridolin.somers at biblibre.com  Tue Apr 12 11:23:43 2022
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Tue, 12 Apr 2022 11:23:43 +0200
Subject: [Koha-devel] Koha 22.05 release dates
Message-ID: <6b7e68f4-ac54-a602-3f8a-74e9794b9968@biblibre.com>

Hi dear community,

Here is the timeline for the 22.05 major release:

* April 29 - "Soft" feature freeze : nothing big or with high risk of
side-effects will be included into the final release if not marked as
Passed QA
* Mai 6 - "Hard" feature freeze : nothing considered as an
improvement will be pushed if not marked as Passed QA
* Mai 11 - String freeze : draft of release notes published
* Mai 18 - Beta : Only bug fixes considered major, critical or blocker
will be pushed
* Mai 26 - Final release

Let me know if you have any request ;)

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

From oleonard at myacpl.org  Tue Apr 12 15:08:10 2022
From: oleonard at myacpl.org (Owen Leonard)
Date: Tue, 12 Apr 2022 09:08:10 -0400
Subject: [Koha-devel] Koha 22.05 release dates
In-Reply-To: <6b7e68f4-ac54-a602-3f8a-74e9794b9968@biblibre.com>
References: <6b7e68f4-ac54-a602-3f8a-74e9794b9968@biblibre.com>
Message-ID: <CAO4qe2MeRw-r1Rh9rL4dnm5_jGiDkRVtrozfhZBsW+p_kG+cLQ@mail.gmail.com>

> * April 29 - "Soft" feature freeze : nothing big or with high risk of
> side-effects will be included into the final release if not marked as

If I may make a request, I'd love to see Bug 29155 make it in: Upgrade
jquery version. This patches some known vulnerabilities in the jQuery
version we have in the OPAC and staff client.

Still looking for a signoff!

Thanks,

  Owen

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

From paul.derscheid at lmscloud.de  Tue Apr 12 17:47:26 2022
From: paul.derscheid at lmscloud.de (Paul Derscheid)
Date: Tue, 12 Apr 2022 17:47:26 +0200
Subject: [Koha-devel] shelf-browser replacement for koha
Message-ID: <6D0704D1-293A-4999-AEF8-0076573628C2@lmscloud.de>

Hi everyone,

I developed a replacement for the koha shelf-browser realised as a JavaScript library which is already in production with one of our clients.
tcohen asked me to provide necessary infos and resources so others can take a look.

The most important part is LMSCoverFlow.js <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/koha-tmpl/opac-tmpl/bootstrap/js/LMSCoverFlow.js> which is the library itself.
For the actual function calls take a look at opac-detail.tt <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-detail.tt> starting at line 1710.
The shelf-browser functionality depends on some scripts, namely coverflowbyshelfitem <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/opac/svc/coverflowbyshelfitem> and covergen <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/opac/svc/covergen>
The corresponding modules are CoverFlowData.pm <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/C4/CoverFlowData.pm> and CoverGen.pm <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/C4/CoverGen.pm>.
I already got lectured on not putting stuff in C4. Next goal is to move everything data related to an API endpoint. 
The js is actually written in TypeScript using ES6 modules and I will change the visibility of the corresponding repo soon and notify you accordingly.

Since the shelf browser is based on itemcallnumbers, it is necessary to assign such to a sufficient amount of titles (9 when I tested on koha-testing-docker).

To see how it looks in prod take a look at this OPAC <https://sb-heilbronn.lmscloud.net/>.

If my explanation is not sufficient or I should have forgotten something, you can send me a mail or write to me on IRC. My nick is paulderscheid.

I’d love to get feedback and I’m open to criticism.

Kind Regards.

Paul

--
LMSCloud GmbH
Paul Derscheid - Software Engineer
Konrad-Zuse-Platz 8 - D-81829 München
e paul.derscheid at lmscloud.de
w www.lmscloud.de

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

From dcook at prosentient.com.au  Wed Apr 13 01:53:04 2022
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Wed, 13 Apr 2022 09:53:04 +1000
Subject: [Koha-devel] Koha 22.05 release dates
In-Reply-To: <CAO4qe2MeRw-r1Rh9rL4dnm5_jGiDkRVtrozfhZBsW+p_kG+cLQ@mail.gmail.com>
References: <6b7e68f4-ac54-a602-3f8a-74e9794b9968@biblibre.com>
 <CAO4qe2MeRw-r1Rh9rL4dnm5_jGiDkRVtrozfhZBsW+p_kG+cLQ@mail.gmail.com>
Message-ID: <046901d84ec8$7f0e29d0$7d2a7d70$@prosentient.com.au>

+1 from me for Bug 29155. 

Owen, I'll look at getting that signoff down now. I recently backported these jQuery and jQuery UI updates to an older version of Koha (for reasons), and it worked very well. I thought it would be scary but jQuery Migrate really makes the upgrade a breeze. 

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: Tuesday, 12 April 2022 11:08 PM
To: koha-devel <koha-devel at lists.koha-community.org>
Cc: koha at lists.katipo.co.nz
Subject: Re: [Koha-devel] Koha 22.05 release dates

> * April 29 - "Soft" feature freeze : nothing big or with high risk of 
> side-effects will be included into the final release if not marked as

If I may make a request, I'd love to see Bug 29155 make it in: Upgrade jquery version. This patches some known vulnerabilities in the jQuery version we have in the OPAC and staff client.

Still looking for a signoff!

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 kohanews at gmail.com  Wed Apr 13 10:00:28 2022
From: kohanews at gmail.com (Koha Newsletter)
Date: Wed, 13 Apr 2022 10:00:28 +0200
Subject: [Koha-devel] Call for news - Newsletter April 2022
Message-ID: <CAEqgz_==hHDR0MmSfOetm5Ad2od6JzZNCTdKJjK3ABgtM_dV0A@mail.gmail.com>

Hi

I'm collecting news for the April 2022 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/20220413/3db1c421/attachment.htm>

From victor at tuxayo.net  Mon Apr 18 01:13:43 2022
From: victor at tuxayo.net (Victor Grousset/tuxayo)
Date: Mon, 18 Apr 2022 01:13:43 +0200
Subject: [Koha-devel] Release maintenance: Monthly string freeze: shall
 it be announced also on koha-devel and the general list?
In-Reply-To: <ffc6babd-9a23-976c-e499-194b7a9f3e27@web.de>
References: <a9078590-293a-ed7d-d1f7-fa2c96638cfb@tuxayo.net>
 <ffc6babd-9a23-976c-e499-194b7a9f3e27@web.de>
Message-ID: <99e9b4c8-0a7a-1dff-22d7-46f26aa096d3@tuxayo.net>

On 22-03-24 21:07, Katrin Fischer wrote:
> I think as we have a dedicated list we should not do too extensive cross
> posting. But if we wan to send to a second list, maybe Koha?


Ok let's roll with that :)


-- 
Victor Grousset/tuxayo

From dcook at prosentient.com.au  Tue Apr 19 04:03:38 2022
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Tue, 19 Apr 2022 12:03:38 +1000
Subject: [Koha-devel] Google showing "Borrow" option for nearby public
 libraries
Message-ID: <00a501d85391$b11a3e00$134eba00$@prosentient.com.au>

Hi all,

 

I was looking up a book the other day on Google when I noticed a section
called "Borrow" and it showed two local library services where I could
borrow the book.

 

I did a bit more Googling today and noticed this:
https://developers.google.com/search/docs/advanced/structured-data/book

 

It looks like individual libraries would need to register their interest
first, but after that the system would need to serve a feed file that Google
would regularly harvest. 

 

Does anyone have a Koha library where they're currently doing this? It could
make for an interesting Koha plugin. 

 

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/20220419/83456974/attachment.htm>

From tomascohen at gmail.com  Tue Apr 19 04:20:40 2022
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Mon, 18 Apr 2022 23:20:40 -0300
Subject: [Koha-devel] Google showing "Borrow" option for nearby public
 libraries
In-Reply-To: <00a501d85391$b11a3e00$134eba00$@prosentient.com.au>
References: <00a501d85391$b11a3e00$134eba00$@prosentient.com.au>
Message-ID: <CABZfb=X4+KiMa1=s3Awi1Pru_nDB+xa4tsupKHCMbk6JSMg1Pw@mail.gmail.com>

I'd say it is a neat core feature as well! Nice finding!!

El lun, 18 abr 2022 23:04, <dcook at prosentient.com.au> escribió:

> Hi all,
>
>
>
> I was looking up a book the other day on Google when I noticed a section
> called “Borrow” and it showed two local library services where I could
> borrow the book.
>
>
>
> I did a bit more Googling today and noticed this:
> https://developers.google.com/search/docs/advanced/structured-data/book
>
>
>
> It looks like individual libraries would need to register their interest
> first, but after that the system would need to serve a feed file that
> Google would regularly harvest.
>
>
>
> Does anyone have a Koha library where they’re currently doing this? It
> could make for an interesting Koha plugin.
>
>
>
> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220418/ca5c39e4/attachment.htm>

From dcook at prosentient.com.au  Tue Apr 19 04:31:32 2022
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Tue, 19 Apr 2022 12:31:32 +1000
Subject: [Koha-devel] Google showing "Borrow" option for nearby public
 libraries
In-Reply-To: <CABZfb=X4+KiMa1=s3Awi1Pru_nDB+xa4tsupKHCMbk6JSMg1Pw@mail.gmail.com>
References: <00a501d85391$b11a3e00$134eba00$@prosentient.com.au>
 <CABZfb=X4+KiMa1=s3Awi1Pru_nDB+xa4tsupKHCMbk6JSMg1Pw@mail.gmail.com>
Message-ID: <00b501d85395$95a7bc20$c0f73460$@prosentient.com.au>

Thanks!

 

Here’s an example of the links that I see where <ISBN> is replaced with the ISBN of what you’re searching:

 

http://link.randwick.nsw.gov.au/id/isbn/<ISBN>/resource/borrow?share=g

 

The two library councils I’m seeing both use the same library system but they belong to different local government entities (one in the east and one in the west).  The URLs are government URLs, but I imagine it was the ILS/LMS vendor who spear-headed the effort. 

 

David Cook

Senior Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Tomas Cohen Arazi <tomascohen at gmail.com> 
Sent: Tuesday, 19 April 2022 12:21 PM
To: David Cook <dcook at prosentient.com.au>
Cc: koha-devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] Google showing "Borrow" option for nearby public libraries

 

I'd say it is a neat core feature as well! Nice finding!!

 

El lun, 18 abr 2022 23:04, <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> > escribió:

Hi all,

 

I was looking up a book the other day on Google when I noticed a section called “Borrow” and it showed two local library services where I could borrow the book.

 

I did a bit more Googling today and noticed this: https://developers.google.com/search/docs/advanced/structured-data/book

 

It looks like individual libraries would need to register their interest first, but after that the system would need to serve a feed file that Google would regularly harvest. 

 

Does anyone have a Koha library where they’re currently doing this? It could make for an interesting Koha plugin. 

 

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 <mailto: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/20220419/95863bd8/attachment.htm>

From victor at tuxayo.net  Tue Apr 19 05:00:06 2022
From: victor at tuxayo.net (Victor Grousset/tuxayo)
Date: Tue, 19 Apr 2022 05:00:06 +0200
Subject: [Koha-devel] Collecting ideas to have an easier time with large
 patch submissions. And inventory of large submissions that are stuck.
Message-ID: <68196e45-4d6f-b4d3-8545-51cb58db5cb6@tuxayo.net>

Hi :)

At the development IRC meeting of 6 April 2022 it was discussed what 
could be done to help large developments better move forward using the 
recent experience with recalls patches (bug 19532).

Here is what came out of it:
- resist scope creep and ask only for necessary changes for inclusion 
(Minimun Viable Product)
- ask to focus discussions on concrete actions for the dev to reach an 
acceptable MVP
- note somewhere all the potential follow ups ideas so that they don't 
get lost and it easier to move on knowing they are somewhere not lost
- bring the development as a topic in meetings and QA team discussions 
to get focus on it

What do you think of these? Any other ideas/guidelines to complete this?

What are the large patch submissions that are stuck that you know about? 
If you could send messages in the past in the ticket, what would you 
sent that would have hopefully helped it move forward?


Here are some other ideas:

- When submitting large changes, submit a minimal version first if 
possible and if a more complete version might be too much. Even if it 
will be hard to maintain a separate more complete version for your 
customers. If it gets stuck, it will be worse than doing it in chunks.
- Maybe reboot a submission on a new ticket with a chopped down version 
if noticing you should have went for the previous guideline.
- Maybe propose taking on testing complicated stuff of someone else if 
they do the same for your submission. It will be worth your time if it 
avoids being stuck for months/years with dozens of rebases on the ticket 
plus on your customer's Kohas due to it being a effectively a fork.


Cheers,

-- 
Victor Grousset/tuxayo

From domm at plix.at  Tue Apr 19 14:12:45 2022
From: domm at plix.at (Thomas Klausner)
Date: Tue, 19 Apr 2022 14:12:45 +0200
Subject: [Koha-devel] Plack Middleware to isolate library branches via path
Message-ID: <20220419121245.GK3952@plix.at>

Hi!

A customer wants to access branches/branchgroups via a subpath, instead 
of the more common / documented way of setting up a subdomain per 
branch:
https://wiki.koha-community.org/wiki/Override_sysprefs_in_Apache_config

So instead of https://aaa.library.example.com/ they want 
https://library.example.com/aaa/  (for ~10 branches)


This boils down to:
- matching the path and munging the URL
- setting some ENV vars (OPAC_SEARCH_LIMIT, OPAC_CSS_OVERRIDE, etc)
- munging the HTML generated by Koha to fix the links

While this could be implemented via carefull application of various 
Apache modules (mod_proxy, mod_rewrite, mod_proxy_html) I feel more 
comfortable implementing this in Perl in a Plack Middleware.
The result is not very pretty, but seems to work (see attached code...)

But to load the middleware, I have to enable it in /etc/koha/plack.psgi 
and thus change a core file (or copy upstream plack.psgi and edit the 
copy, which still means that we'll have to apply our changes after each 
update)

In theory we could add some config to load custom Middlewares, but as 
the load order of Middlewares is very relevant, this seems hardly doable 
- unless we start with one middleware config slot at the location I need :-)

Anyway, I think we'll just go with maintaining a custom plack.psgi, 
unless anybody here has any other ideas / best practices / solutions on 
how to mount library branches at location/sub-dirs... I'm also not sure 
if this feature is on any roadmap etc.


Greetings,
domm


-- 
#!/usr/bin/perl                             https://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IsolateBranch.pm
Type: text/x-perl
Size: 2447 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220419/6cc9a231/attachment.pm>

From dcook at prosentient.com.au  Wed Apr 20 02:56:36 2022
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Wed, 20 Apr 2022 10:56:36 +1000
Subject: [Koha-devel] Plack Middleware to isolate library branches via
 path
In-Reply-To: <20220419121245.GK3952@plix.at>
References: <20220419121245.GK3952@plix.at>
Message-ID: <016501d85451$81be5bd0$853b1370$@prosentient.com.au>

Hi Thomas,

The timing of your email is interesting! I was just reflecting the other day
about how Koha can't work off anything but the root path. 

However, it's not something that I'm likely to ever work on, as the
subdomains work fine for us. (Although self-checkout URLs using branch-based
paths could be very useful for us.)

I have a Catalyst app where I use the out of the box method $c->uri_for
which constructs an absolute URI using the application root (e.g. /aaa/),
but that would require rewriting Koha's templates. I use that same strategy
for some of my other web apps, which lets the deployment be quite flexible.
(In the case of Catalyst, it auto-detects the path based on the location of
the controller. With CGI apps I have, I rely on a configuration variable.)

With your solution, how do you handle Javascript navigation that doesn't
necessarily rely on HTML? (I can't think of any examples off the top of my
head but I'm sure they must exist, although perhaps only on the Staff
Interface...)

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
Thomas Klausner
Sent: Tuesday, 19 April 2022 10:13 PM
To: koha-devel at lists.koha-community.org
Subject: [Koha-devel] Plack Middleware to isolate library branches via path

Hi!

A customer wants to access branches/branchgroups via a subpath, instead of
the more common / documented way of setting up a subdomain per
branch:
https://wiki.koha-community.org/wiki/Override_sysprefs_in_Apache_config

So instead of https://aaa.library.example.com/ they want
https://library.example.com/aaa/  (for ~10 branches)


This boils down to:
- matching the path and munging the URL
- setting some ENV vars (OPAC_SEARCH_LIMIT, OPAC_CSS_OVERRIDE, etc)
- munging the HTML generated by Koha to fix the links

While this could be implemented via carefull application of various 
Apache modules (mod_proxy, mod_rewrite, mod_proxy_html) I feel more 
comfortable implementing this in Perl in a Plack Middleware.
The result is not very pretty, but seems to work (see attached code...)

But to load the middleware, I have to enable it in /etc/koha/plack.psgi 
and thus change a core file (or copy upstream plack.psgi and edit the 
copy, which still means that we'll have to apply our changes after each 
update)

In theory we could add some config to load custom Middlewares, but as 
the load order of Middlewares is very relevant, this seems hardly doable 
- unless we start with one middleware config slot at the location I need :-)

Anyway, I think we'll just go with maintaining a custom plack.psgi, 
unless anybody here has any other ideas / best practices / solutions on 
how to mount library branches at location/sub-dirs... I'm also not sure 
if this feature is on any roadmap etc.


Greetings,
domm


-- 
#!/usr/bin/perl                             https://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}


From naveen at neduet.edu.pk  Wed Apr 20 07:10:49 2022
From: naveen at neduet.edu.pk (Ms. Naveen Ali)
Date: Wed, 20 Apr 2022 10:10:49 +0500 (PKT)
Subject: [Koha-devel] How to apply Lending Restrictions
In-Reply-To: <617164150.1137489.1650423594912.JavaMail.zimbra@neduet.edu.pk>
Message-ID: <1673116620.1147324.1650431449576.JavaMail.zimbra@neduet.edu.pk>

Dear members, 

I would like to put forward the following scenario. 

Our library has three sections where books are loaned and they each have different policies. All library members have access to all sections. 

I would like to implement the library policy where 


    1. staff of one section can issue books of that section only 
    2. books should also be returned to the same section. 
There is no general rule; just specific rules for each section. 

This is what I am doing. 

I have provided Permanent Library of all book items as the main library name and the Current Library as the section library. 

I am trying to use the following global parameters to implement our library policies, but am not successful. 



    * AllowReturnToBranch 
	
Allow items to be checked in "Only at the item the library is from" (I understand this to be the current library) 


    * AutomaticItemReturn 
	
Don't automatically transfer items to their home library when they are checked in. (I understand the home library to be the permanent library) 



    * CircControl Use the calendar and circulation rules of "the library the item is from" (I understand this to be the current library) 
	




    * HomeOrHoldingBranch 
	
Use the checkout and fines rules of " the items holding library" (I understand holding library = current library and home library = permanent library) 

*It seems that CircControl and HomeOrHoldingBranch paramter are same. 

I also can't find how to restrict a library staff member from Setting his library to any that he wants by using the "Set Library" Option available. 
Also how to prevent staff from issuing books belonging to other libraries. 


With best regards, 

Naveen Ali 

ITM-JE (EAKL) 
Inst Representative for 
HEC Digital Library Resources. 
NEDUET, Karachi. 


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

From domm at plix.at  Wed Apr 20 10:00:31 2022
From: domm at plix.at (Thomas Klausner)
Date: Wed, 20 Apr 2022 10:00:31 +0200
Subject: [Koha-devel] Plack Middleware to isolate library branches via
 path
In-Reply-To: <016501d85451$81be5bd0$853b1370$@prosentient.com.au>
References: <20220419121245.GK3952@plix.at>
 <016501d85451$81be5bd0$853b1370$@prosentient.com.au>
Message-ID: <20220420080031.GO3952@plix.at>

Hi!

On Wed, Apr 20, 2022 at 10:56:36AM +1000, dcook at prosentient.com.au wrote:
 
> The timing of your email is interesting! I was just reflecting the other day
> about how Koha can't work off anything but the root path. 

:-)

> I have a Catalyst app where I use the out of the box method $c->uri_for
> which constructs an absolute URI using the application root (e.g. /aaa/),
> but that would require rewriting Koha's templates. I use that same strategy

Most web frameworks and/or router implementations provide methods to 
generate links, and those methods should honor HTTP headers like 
X-Forwarded-For etc. I usually use Plack::Middleware::ReverseProxyPath
https://metacpan.org/pod/Plack::Middleware::ReverseProxyPath
which uses X-Forwarded-Script-Name and X-Traversal-Path to allow for a 
very flexible setup, if the apps/routers used support those headers to 
generate links (Catalyst does, AFAIK)

But I guess the reason that Koha cannot use somethink like this is that 
it generates a lot of links via literal strings in the templates. And 
changing this to use a method/function would be a lot of work!

Which is why I choose the rather ugly and probably not very stable 
approach to fix (hopefully..) the generated URLs after rendering using a 
regex...

> With your solution, how do you handle Javascript navigation that doesn't
> necessarily rely on HTML? (I can't think of any examples off the top of my
> head but I'm sure they must exist, although perhaps only on the Staff
> Interface...)

Currently we don't, but the users are as of now only starting to test 
the path-based branches. We'll see what problems they'll encounter. And 
we're only using this branch separation on the OPAC.

Greetings,
domm

-- 
#!/usr/bin/perl                             https://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

From victor at tuxayo.net  Wed Apr 20 17:04:53 2022
From: victor at tuxayo.net (Victor Grousset/tuxayo)
Date: Wed, 20 Apr 2022 17:04:53 +0200
Subject: [Koha-devel] Terminology: addition of "use restriction,
 not debarment"
Message-ID: <0ac43574-a4cc-620c-359b-9fdcf33b94b6@tuxayo.net>

Hi :)

After last dev meeting of the 6th, the following addition has been done:
https://wiki.koha-community.org/w/index.php?title=Terminology&action=historysubmit&diff=30449&oldid=30265

Whole page: https://wiki.koha-community.org/wiki/Terminology

Cheers,

-- 
Victor Grousset/tuxayo

From victor at tuxayo.net  Wed Apr 20 18:37:53 2022
From: victor at tuxayo.net (Victor Grousset/tuxayo)
Date: Wed, 20 Apr 2022 18:37:53 +0200
Subject: [Koha-devel] Vote: Use Vue3 for the new ERM (Electronic Resource
 Management) module
Message-ID: <bc12e6a2-d5f0-49e2-d19e-897bfeecd3dc@tuxayo.net>

Hi :)

At last meeting, today, it has been voted to give a go to have Vue3 JS 
framework be used for the new ERM module.

Here is the same question to have a wider reach than only the people 
that were able to attend.
So, agreed with that? Or any objections?

Let's wait a few days and if no major objection, Jonathan will be able 
to continue the ERM module knowing Vue won't be a problem for the patch 
acceptance in Koha.

meeting logs: http://irc.koha-community.org/koha/2022-04-20#i_2416969

Email asking for the vote and listing all the resources about the ERM 
project 
https://lists.koha-community.org/pipermail/koha-devel/2022-April/046998.html

Cheers,

-- 
Victor Grousset/tuxayo

From michael.hafen at washk12.org  Wed Apr 20 19:20:34 2022
From: michael.hafen at washk12.org (Michael Hafen (TECH))
Date: Wed, 20 Apr 2022 11:20:34 -0600
Subject: [Koha-devel] How to apply Lending Restrictions
In-Reply-To: <1673116620.1147324.1650431449576.JavaMail.zimbra@neduet.edu.pk>
References: <617164150.1137489.1650423594912.JavaMail.zimbra@neduet.edu.pk>
 <1673116620.1147324.1650431449576.JavaMail.zimbra@neduet.edu.pk>
Message-ID: <CAAh7Ud=s8zVPBWaHckx5oQCvdK84H5XVCz0DxFT6ZnU1T6_30A@mail.gmail.com>

It may be a bit drastic, but if this is the only library on this Koha
system you could try turning each section into a branch and turning on
independent branches.
Separate branches would allow for different rules without drastically
increasing the number of item types, and staff would be at a certain
branch.  Turning on independent branches would effectively restrict them to
their section.  You could even hold the independent branches setting for a
bit to see if it works to have each section as a separate branch.


On Tue, Apr 19, 2022 at 11:15 PM Ms. Naveen Ali <naveen at neduet.edu.pk>
wrote:

> Dear members,
>
> I would like to put forward the following scenario.
>
> Our library has three sections where books are loaned and they each have
> different policies. All library members have access to all sections.
>
> I would like to implement the library policy where
>
>    1. staff of one section can issue books of that section only
>    2. books should also be returned to the same section.
>
> There is no general rule; just specific rules for each section.
>
> This is what I am doing.
>
> I have provided Permanent Library of all book items as the main library
> name and the Current Library as the section library.
>
> I am trying to use the following global parameters to implement our
> library policies, but am not successful.
>
>
>    - AllowReturnToBranch
>
> Allow items to be checked in "Only at the item the library is from" (I
> understand this to be the current library)
>
>    - AutomaticItemReturn
>
>  Don't automatically transfer items to their home library when they are
> checked in. (I understand the home library to be the permanent library)
>
>
>    - CircControl Use the calendar and circulation rules of "the library
>    the item is from" (I understand this to be the current library)
>
>
>
>
>    - HomeOrHoldingBranch
>
> Use the checkout and fines rules of " the items holding library" (I
> understand holding library = current library and home library = permanent
> library)
>
> *It seems that CircControl and HomeOrHoldingBranch paramter are same.
>
> I also can't find how to restrict a library staff member from Setting his
> library to any that he wants by using the "Set Library" Option available.
> Also how to prevent staff from issuing books belonging to other libraries.
>
>
> *With best regards,*
>
> *Naveen Ali*
>
> **
> *ITM-JE (EAKL)*
> *Inst Representative for *
> *HEC Digital Library Resources.*
> *NEDUET, Karachi.*
>
>
>
> _______________________________________________
> 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/
>


-- 
Michael Hafen
Washington County School District Technology Department
Systems Analyst
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220420/a2a20ce8/attachment.htm>

From katrin.fischer.83 at web.de  Thu Apr 21 17:13:18 2022
From: katrin.fischer.83 at web.de (Katrin Fischer)
Date: Thu, 21 Apr 2022 17:13:18 +0200
Subject: [Koha-devel] shelf-browser replacement for koha
In-Reply-To: <6D0704D1-293A-4999-AEF8-0076573628C2@lmscloud.de>
References: <6D0704D1-293A-4999-AEF8-0076573628C2@lmscloud.de>
Message-ID: <d2f734bb-4d15-b7df-3be4-f9fe1071f180@web.de>

Hi Paul,

welcome to the list :)

I tried to take a look at the feature, but when I try to load the shelf
browser, it remains empty or takes a long while to load. There are some
errors in the console (mostly CORS Missing Allow Origin) that could
relate to the problem.

Maybe adding a visual indicator about the content still loading could be
a nice addition.

I quite like the idea of generating a nice replacement picture for
missing covers.

Hope this helps,

Katrin


On 12.04.22 17:47, Paul Derscheid wrote:
> Hi everyone,
>
> I developed a replacement for the koha shelf-browser realised as a
> JavaScript library which is already in production with one of our clients.
> tcohen asked me to provide necessary infos and resources so others can
> take a look.
>
>   * The most important part is LMSCoverFlow.js
>     <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/koha-tmpl/opac-tmpl/bootstrap/js/LMSCoverFlow.js> which
>     is the library itself.
>   * For the actual function calls take a look at opac-detail.tt
>     <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-detail.tt> starting
>     at line 1710.
>   * The shelf-browser functionality depends on some scripts, namely
>     coverflowbyshelfitem
>     <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/opac/svc/coverflowbyshelfitem> and
>     covergen
>     <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/opac/svc/covergen>
>   * The corresponding modules are CoverFlowData.pm
>     <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/C4/CoverFlowData.pm> and
>     CoverGen.pm
>     <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/C4/CoverGen.pm>.
>
> I already got lectured on not putting stuff in C4. Next goal is to
> move everything data related to an API endpoint.
> The js is actually written in TypeScript using ES6 modules and I will
> change the visibility of the corresponding repo soon and notify you
> accordingly.
>
> Since the shelf browser is based on itemcallnumbers, it is necessary
> to assign such to a sufficient amount of titles (9 when I tested on
> koha-testing-docker).
>
> To see how it looks in prod take a look at this OPAC
> <https://sb-heilbronn.lmscloud.net/>.
>
> If my explanation is not sufficient or I should have forgotten
> something, you can send me a mail or write to me on IRC. My nick is
> paulderscheid.
>
> I’d love to get feedback and I’m open to criticism.
>
> Kind Regards.
>
> Paul
>
> --
> LMSCloud GmbH
> Paul Derscheid - Software Engineer
> Konrad-Zuse-Platz 8 - D-81829 München
> e paul.derscheid at lmscloud.de
> w www.lmscloud.de <http://www.lmscloud.de>
>
>
> _______________________________________________
> 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/20220421/9cdc7913/attachment.htm>

From paul.derscheid at lmscloud.de  Thu Apr 21 17:57:15 2022
From: paul.derscheid at lmscloud.de (Paul Derscheid)
Date: Thu, 21 Apr 2022 17:57:15 +0200
Subject: [Koha-devel] shelf-browser replacement for koha
In-Reply-To: <d2f734bb-4d15-b7df-3be4-f9fe1071f180@web.de>
References: <6D0704D1-293A-4999-AEF8-0076573628C2@lmscloud.de>
 <d2f734bb-4d15-b7df-3be4-f9fe1071f180@web.de>
Message-ID: <2249634.iZASKD2KPV@moon>

On Donnerstag, 21. April 2022 17:13:18 CEST Katrin Fischer wrote:
> Hi Paul,
> 
> welcome to the list :)
> 
> I tried to take a look at the feature, but when I try to load the shelf
> browser, it remains empty or takes a long while to load. There are some
> errors in the console (mostly CORS Missing Allow Origin) that could
> relate to the problem.
> 
> Maybe adding a visual indicator about the content still loading could be
> a nice addition.
> 
> I quite like the idea of generating a nice replacement picture for
> missing covers.
> 
> Hope this helps,
> 
> Katrin
> 
> On 12.04.22 17:47, Paul Derscheid wrote:
> > Hi everyone,
> > 
> > I developed a replacement for the koha shelf-browser realised as a
> > JavaScript library which is already in production with one of our clients.
> > tcohen asked me to provide necessary infos and resources so others can
> > take a look.
> > 
> >   * The most important part is LMSCoverFlow.js
> >   
> >     <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/koha-tmpl/opac-> >     tmpl/bootstrap/js/LMSCoverFlow.js> which is the library itself.
> >   
> >   * For the actual function calls take a look at opac-detail.tt
> >   
> >     <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/koha-tmpl/opac-> >     tmpl/bootstrap/en/modules/opac-detail.tt> starting at line 1710.
> >   
> >   * The shelf-browser functionality depends on some scripts, namely
> >   
> >     coverflowbyshelfitem
> >     <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/opac/svc/coverf
> >     lowbyshelfitem> and covergen
> >     <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/opac/svc/coverg
> >     en>
> >   
> >   * The corresponding modules are CoverFlowData.pm
> >   
> >     <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/C4/CoverFlowDat
> >     a.pm> and CoverGen.pm
> >     <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/C4/CoverGen.pm>
> >     .
> > 
> > I already got lectured on not putting stuff in C4. Next goal is to
> > move everything data related to an API endpoint.
> > The js is actually written in TypeScript using ES6 modules and I will
> > change the visibility of the corresponding repo soon and notify you
> > accordingly.
> > 
> > Since the shelf browser is based on itemcallnumbers, it is necessary
> > to assign such to a sufficient amount of titles (9 when I tested on
> > koha-testing-docker).
> > 
> > To see how it looks in prod take a look at this OPAC
> > <https://sb-heilbronn.lmscloud.net/>.
> > 
> > If my explanation is not sufficient or I should have forgotten
> > something, you can send me a mail or write to me on IRC. My nick is
> > paulderscheid.
> > 
> > I’d love to get feedback and I’m open to criticism.
> > 
> > Kind Regards.
> > 
> > Paul
> > 
> > --
> > LMSCloud GmbH
> > Paul Derscheid - Software Engineer
> > Konrad-Zuse-Platz 8 - D-81829 München
> > e paul.derscheid at lmscloud.de
> > w www.lmscloud.de <http://www.lmscloud.de>
> > 
> > 
> > _______________________________________________
> > 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/

Hello Katrin,

thanks for trying it out. I'm currently moving everything data-related
to an API-endpoint as well as fixing some bugs and I will provide a better 
solution for testing the feature than just listing the necessary files as
soon as I'm done.

I forgot to mention that you have to enable a provider for cover images.
Google works reasonably well. 

If I'm not mistaken the CORS issue stems from EKZ being the default
cover image provider in my configuration and there's maybe some mishap
there because they face some problems atm (don't know if I'm allowed
to go into specifics, so I won't).

A visual indicator for bridging the loading process is already 
implemented but apparently gets called too late to be of significance so
thanks for mentioning that.

The CoverGen script I mentioned in my first mail is intended to
generate cover images for resources which are missing urls. I noticed
some bugs there, though. This is also not default behaviour but will be
in the next version.

I appreciate your input, so thanks again.

Kind regards

Paul Derscheid
 
--
LMSCloud GmbH
Paul Derscheid - Software Engineer
Konrad-Zuse-Platz 8 - D-81829 München
e paul.derscheid at lmscloud.de
w www.lmscloud.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220421/b40299f5/attachment.sig>

From nick at bywatersolutions.com  Fri Apr 22 20:51:56 2022
From: nick at bywatersolutions.com (Nick Clemens)
Date: Fri, 22 Apr 2022 14:51:56 -0400
Subject: [Koha-devel] Adding recent (current/past year) statistics to the
 items table
Message-ID: <CAA_eX3NMs0Gx+2z_xYWvmy_3zq_5vJsnkmTS5RG68LCNxmNDmg@mail.gmail.com>

Hi All,

We have had several requests recently for an easy way to access
current/last year's circulation stats for items, without having to create
reports totalling these numbers. The numbers here are used for weeding,
state reporting, etc.

Other systems have fields: 'Year to date circ' and 'last year circ'

We have discussed several possible developments:
 - a new table to track these
 - adding a new field, or altering 'issues' to use JSON and storing
circ/renewal counts by year
 - adding two new fields to the items table and use a cronjob to move
'current year' circ to 'last years circ' at the end of the year.

We wanted to check in with the community to see if this is a request that
others have or have seen, and how they handle these.

Thanks for any info.
Nick (kidclamp)

-- 
Nick Clemens
ByWater Solutions
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220422/b17c6437/attachment.htm>

From michael.hafen at washk12.org  Fri Apr 22 21:32:33 2022
From: michael.hafen at washk12.org (Michael Hafen (TECH))
Date: Fri, 22 Apr 2022 13:32:33 -0600
Subject: [Koha-devel] Adding recent (current/past year) statistics to
 the items table
In-Reply-To: <CAA_eX3NMs0Gx+2z_xYWvmy_3zq_5vJsnkmTS5RG68LCNxmNDmg@mail.gmail.com>
References: <CAA_eX3NMs0Gx+2z_xYWvmy_3zq_5vJsnkmTS5RG68LCNxmNDmg@mail.gmail.com>
Message-ID: <CAAh7Ud=He2POBaBaULMF7OwGsM5v6n7H7-cK86fxFnZSmiK-fQ@mail.gmail.com>

I have schools using Koha here, and those are reports that my schools asked
for.  I built reports for them, but Guided Reports could probably take care
of them too.

On Fri, Apr 22, 2022 at 12:52 PM Nick Clemens <nick at bywatersolutions.com>
wrote:

> Hi All,
>
> We have had several requests recently for an easy way to access
> current/last year's circulation stats for items, without having to create
> reports totalling these numbers. The numbers here are used for weeding,
> state reporting, etc.
>
> Other systems have fields: 'Year to date circ' and 'last year circ'
>
> We have discussed several possible developments:
>  - a new table to track these
>  - adding a new field, or altering 'issues' to use JSON and storing
> circ/renewal counts by year
>  - adding two new fields to the items table and use a cronjob to move
> 'current year' circ to 'last years circ' at the end of the year.
>
> We wanted to check in with the community to see if this is a request that
> others have or have seen, and how they handle these.
>
> Thanks for any info.
> Nick (kidclamp)
>
> --
> Nick Clemens
> ByWater Solutions
> 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 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/
>


-- 
Michael Hafen
Washington County School District Technology Department
Systems Analyst
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220422/4cad254f/attachment.htm>

From dcook at prosentient.com.au  Tue Apr 26 03:13:26 2022
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Tue, 26 Apr 2022 11:13:26 +1000
Subject: [Koha-devel] Does anyone use "Item circulation alerts"?
Message-ID: <056e01d8590a$dee9f810$9cbde830$@prosentient.com.au>

I think today is the first time in 10 years that I've bumped into "Item
circulation alerts". By default, they're enabled for everyone and
everything, and that seems to work. However, today, I noticed a library
where they're disabled alerts for most categories and item types, and then
wondered why they weren't getting item circulation emails. 

 

I wonder if this functionality causes more harm than good these days? Looks
like it was introduced in 2009 and never touched again? 

 

Of course, removing this functionality would probably be easier said than
done, as it would be a behaviour change. so maybe it would need to be
deprecated over time. If no rules exist, we could just hide it. If rules do
exist, we'd alert the staff that this functionality was going away in a
future version? 

 

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/20220426/4a719630/attachment.htm>

From indradg at l2c2.co.in  Tue Apr 26 04:41:50 2022
From: indradg at l2c2.co.in (Indranil Das Gupta)
Date: Tue, 26 Apr 2022 08:11:50 +0530
Subject: [Koha-devel] Does anyone use "Item circulation alerts"?
In-Reply-To: <056e01d8590a$dee9f810$9cbde830$@prosentient.com.au>
References: <056e01d8590a$dee9f810$9cbde830$@prosentient.com.au>
Message-ID: <CAJ0y-Deu4h+yz_-WFU3FPvf=_7443hx5mKZbUnxLkJVtUOO9hQ@mail.gmail.com>

Hi David:

>From our clients in the Indian subcontinent i can certainly vouch that the
functionality *is used* quite frequently because for certain "holy cow"
patron categories / patrons the librarians do not want to attract their ire
by "how dare you tell me I've an overdue item" email.  Not an welcome
scenario, but its a reality in societies stuck somewhere between feudalism
and capitalism.

Removing that feature may result in a large number of Indian users leaving
koha for non standard local software.

Just my 2p.

Cheers
Indranil.

On Tue, 26 Apr, 2022, 6:43 am , <dcook at prosentient.com.au> wrote:

> I think today is the first time in 10 years that I’ve bumped into “Item
> circulation alerts”. By default, they’re enabled for everyone and
> everything, and that seems to work. However, today, I noticed a library
> where they’re disabled alerts for most categories and item types, and then
> wondered why they weren’t getting item circulation emails.
>
>
>
> I wonder if this functionality causes more harm than good these days?
> Looks like it was introduced in 2009 and never touched again?
>
>
>
> Of course, removing this functionality would probably be easier said than
> done, as it would be a behaviour change… so maybe it would need to be
> deprecated over time. If no rules exist, we could just hide it. If rules do
> exist, we’d alert the staff that this functionality was going away in a
> future version?
>
>
>
> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220426/6b8bef8a/attachment.htm>

From dcook at prosentient.com.au  Tue Apr 26 04:49:56 2022
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Tue, 26 Apr 2022 12:49:56 +1000
Subject: [Koha-devel] Does anyone use "Item circulation alerts"?
In-Reply-To: <CAJ0y-Deu4h+yz_-WFU3FPvf=_7443hx5mKZbUnxLkJVtUOO9hQ@mail.gmail.com>
References: <056e01d8590a$dee9f810$9cbde830$@prosentient.com.au>
 <CAJ0y-Deu4h+yz_-WFU3FPvf=_7443hx5mKZbUnxLkJVtUOO9hQ@mail.gmail.com>
Message-ID: <05b401d85918$5427eee0$fc77cca0$@prosentient.com.au>

Hi Indranil,

 

That’s good to know! I’m glad that I asked. 

 

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: Indranil Das Gupta <indradg at l2c2.co.in> 
Sent: Tuesday, 26 April 2022 12:42 PM
To: dcook at prosentient.com.au
Cc: Koha-devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] Does anyone use "Item circulation alerts"?

 

Hi David:

 

>From our clients in the Indian subcontinent i can certainly vouch that the functionality *is used* quite frequently because for certain "holy cow" patron categories / patrons the librarians do not want to attract their ire by "how dare you tell me I've an overdue item" email.  Not an welcome scenario, but its a reality in societies stuck somewhere between feudalism and capitalism.

 

Removing that feature may result in a large number of Indian users leaving koha for non standard local software.

 

Just my 2p.

 

Cheers

Indranil.

 

On Tue, 26 Apr, 2022, 6:43 am , <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> > wrote:

I think today is the first time in 10 years that I’ve bumped into “Item circulation alerts”. By default, they’re enabled for everyone and everything, and that seems to work. However, today, I noticed a library where they’re disabled alerts for most categories and item types, and then wondered why they weren’t getting item circulation emails. 

 

I wonder if this functionality causes more harm than good these days? Looks like it was introduced in 2009 and never touched again? 

 

Of course, removing this functionality would probably be easier said than done, as it would be a behaviour change… so maybe it would need to be deprecated over time. If no rules exist, we could just hide it. If rules do exist, we’d alert the staff that this functionality was going away in a future version? 

 

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 <mailto: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/20220426/930840db/attachment.htm>

From andrew at bywatersolutions.com  Tue Apr 26 15:22:50 2022
From: andrew at bywatersolutions.com (Andrew Fuerste-Henry)
Date: Tue, 26 Apr 2022 08:22:50 -0500
Subject: [Koha-devel] Koha 21.05.14 Release
Message-ID: <CANGX5Dzgy0SotL0hspVU_O09+Pc87sEifkR+zjOuGnp3g80+dA@mail.gmail.com>

The Koha community is proud to announce the release of version 21.05.14.
This is a maintenance release and contains bug fixes.

For full details and release notes, please see
https://koha-community.org/koha-version-21-05-14-released/

Thanks!
Andrew

-- 
Andrew Fuerste-Henry
Educator
(he/they)
ByWater Solutions
bywatersolutions.com
Phone:(888)900-8944 <(888)%20900-8944>

What is Koha?
<http://bywatersolutions.com/what-is-koha/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220426/ee6c288c/attachment.htm>

From victor at tuxayo.net  Tue Apr 26 17:32:07 2022
From: victor at tuxayo.net (Victor Grousset/tuxayo)
Date: Tue, 26 Apr 2022 17:32:07 +0200
Subject: [Koha-devel] Koha 20.11.18 released
Message-ID: <ab3f6663-7ea4-d6e2-8a84-6103076cc939@tuxayo.net>

Hello! :)

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

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


Debian packages should be available shortly.

Thanks to everyone involved :)


Cheers,

-- 
Victor Grousset/tuxayo

From chrisc at catalyst.net.nz  Tue Apr 26 23:51:54 2022
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Wed, 27 Apr 2022 09:51:54 +1200
Subject: [Koha-devel] Koha version 19.11.29 released
Message-ID: <70b646b3-ad68-99b5-3073-bccac29b0c32@catalyst.net.nz>


Hello everyone!

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

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

Thank you to everyone involved!

Cheers,
Chris Cormack  (Standing in for Te Wainui)

From dcook at prosentient.com.au  Thu Apr 28 06:48:07 2022
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Thu, 28 Apr 2022 14:48:07 +1000
Subject: [Koha-devel] Koha::Item->is_notforloan (see Bug 30636)
Message-ID: <076901d85abb$2ab6d900$80248b00$@prosentient.com.au>

Hi all,

 

While working on
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30636, I noticed
that our usage of Koha::Item->notforloan is problematic. Sometimes we use it
as a Boolean and sometimes we use it for descriptive information. 

 

When we use it as a Boolean, we really should be taking into account the
"Not for loan" status by "Item Type" as well. 

 

I'm noticing there are places in Koha which show an item as "Available" if
the item is "Not for loan" by item type and that's a problem. (It looks like
the new recalls feature from Bug 19532 has this same problem.)

 

Anyway, I'm thinking a new method like Koha::Item->is_notforloan might be a
good idea for covering the Boolean condition rather than trying to remember
to implement Koha::Item->notforloan and Koha::Item->notforloan_per_itemtype
(this method doesn't even exist) for all relevant use cases.

 

One way or another, I'll be fixing the ILS-DI API locally, but I'd like to
get people's input first, so that it's easier for  me to upstream and
benefit everyone else too. 

 

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/20220428/e1ba7542/attachment.htm>

From kohanews at gmail.com  Thu Apr 28 12:01:01 2022
From: kohanews at gmail.com (Koha Newsletter)
Date: Thu, 28 Apr 2022 12:01:01 +0200
Subject: [Koha-devel] Koha Community Newsletter: April 2022
Message-ID: <CAEqgz_n2xrFedqaqMKTxXcfaUyGAAmQHU3QVHYOBiN0XdJ3CNA@mail.gmail.com>

The Koha Community Newsletter for April 2022 is here:

https://koha-community.org/koha-community-newsletter-april-2022/

Many thanks to everyone who submitted articles and news to 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/20220428/9bf8fb42/attachment.htm>

From fridolin.somers at biblibre.com  Thu Apr 28 21:27:39 2022
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Thu, 28 Apr 2022 09:27:39 -1000
Subject: [Koha-devel] Koha::Item->is_notforloan (see Bug 30636)
In-Reply-To: <076901d85abb$2ab6d900$80248b00$@prosentient.com.au>
References: <076901d85abb$2ab6d900$80248b00$@prosentient.com.au>
Message-ID: <0c8367ed-f3de-f7e8-c0a7-836e710ed75d@biblibre.com>

+1

->is_xxx for a boolean makes sens.

Le 27/04/2022 à 18:48, dcook at prosentient.com.au a écrit :
> Hi all,
> 
> While working on 
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30636 
> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30636>, I 
> noticed that our usage of Koha::Item->notforloan is problematic. 
> Sometimes we use it as a Boolean and sometimes we use it for descriptive 
> information.
> 
> When we use it as a Boolean, we really should be taking into account the 
> “Not for loan” status by “Item Type” as well.
> 
> I’m noticing there are places in Koha which show an item as “Available” 
> if the item is “Not for loan” by item type and that’s a problem. (It 
> looks like the new recalls feature from Bug 19532 has this same problem.)
> 
> Anyway, I’m thinking a new method like Koha::Item->is_notforloan might 
> be a good idea for covering the Boolean condition rather than trying to 
> remember to implement Koha::Item->notforloan and 
> Koha::Item->notforloan_per_itemtype (this method doesn’t even exist) for 
> all relevant use cases.
> 
> One way or another, I’ll be fixing the ILS-DI API locally, but I’d like 
> to get people’s input first, so that it’s easier for  me to upstream and 
> benefit everyone else too.
> 
> 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  Thu Apr 28 21:54:35 2022
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Thu, 28 Apr 2022 09:54:35 -1000
Subject: [Koha-devel] [Koha] Roles for 22.11 open
In-Reply-To: <4515e8f2-3d7a-3731-e78f-1044d96434f8@biblibre.com>
References: <4515e8f2-3d7a-3731-e78f-1044d96434f8@biblibre.com>
Message-ID: <263f03d4-14d2-44c1-774c-bd4e7b863077@biblibre.com>

Hi,

Some people have joined the team.

There is still room, specially in Release Manager.
It is a role major for everybody having a Koha in production.

Feel free to ask for more information.

<< Nine companions. So be it. You shall be the fellowship of the ring >>

Best regards,

Le 11/04/2022 à 23:13, Fridolin SOMERS a écrit :
> Hi dear community.
> 
> 22.05 cycle comes to an end, time to think of next cycle.
> 
> The roles for the 22.11 release cycle are now opened :
> https://wiki.koha-community.org/wiki/Roles_for_22.11
> 
> The vote will take place during next general IRC meeting on May 4th.
> 
> The description of the roles can be found at this wiki page :
> https://wiki.koha-community.org/wiki/Project_roles
> 
> << Join us in the dark side, we have cookies >>
> 
> Best regards,
> 

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

From mtj at kohaaloha.com  Fri Apr 29 07:29:28 2022
From: mtj at kohaaloha.com (Mason James)
Date: Fri, 29 Apr 2022 17:29:28 +1200
Subject: [Koha-devel] =?utf-8?q?Koha_releases_are_available_=F0=9F=8E=81?=
Message-ID: <8ea1afa6-cc7a-bd2b-7870-c38b4d4ada8e@kohaaloha.com>

kia ora community,

the latest Koha packages are available

an installation guide is below...
https://wiki.koha-community.org/wiki/Koha_on_Debian


cheers, Mason

From katrin.fischer.83 at web.de  Fri Apr 29 11:24:11 2022
From: katrin.fischer.83 at web.de (Katrin Fischer)
Date: Fri, 29 Apr 2022 11:24:11 +0200
Subject: [Koha-devel] Adding recent (current/past year) statistics to
 the items table
In-Reply-To: <CAAh7Ud=He2POBaBaULMF7OwGsM5v6n7H7-cK86fxFnZSmiK-fQ@mail.gmail.com>
References: <CAA_eX3NMs0Gx+2z_xYWvmy_3zq_5vJsnkmTS5RG68LCNxmNDmg@mail.gmail.com>
 <CAAh7Ud=He2POBaBaULMF7OwGsM5v6n7H7-cK86fxFnZSmiK-fQ@mail.gmail.com>
Message-ID: <3f99f9f6-76ce-a0a5-51fd-f7e14d0954a1@web.de>

Hi Nick and all,

I am a little worried about having yet another 'source of truth' we'll
need to keep in sync and update on every circulation action and added
maintenance for moving it end of year etc.

Maybe we could pull the data from the statistics table into a nice
display or add a new built-in report to make querying this data easier?

Katrin

On 22.04.22 21:32, Michael Hafen (TECH) wrote:
> I have schools using Koha here, and those are reports that my schools
> asked for.  I built reports for them, but Guided Reports could
> probably take care of them too.
>
> On Fri, Apr 22, 2022 at 12:52 PM Nick Clemens
> <nick at bywatersolutions.com> wrote:
>
>     Hi All,
>
>     We have had several requests recently for an easy way to access
>     current/last year's circulation stats for items, without having to
>     create reports totalling these numbers. The numbers here are used
>     for weeding, state reporting, etc.
>
>     Other systems have fields: 'Year to date circ' and 'last year circ'
>
>     We have discussed several possible developments:
>      - a new table to track these
>      - adding a new field, or altering 'issues' to use JSON and
>     storing circ/renewal counts by year
>      - adding two new fields to the items table and use a cronjob to
>     move 'current year' circ to 'last years circ' at the end of the year.
>
>     We wanted to check in with the community to see if this is a
>     request that others have or have seen, and how they handle these.
>
>     Thanks for any info.
>     Nick (kidclamp)
>
>     --
>     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 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/
>
>
>
> --
> Michael Hafen
> Washington County School District Technology Department
> Systems Analyst
>
>
> _______________________________________________
> 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/20220429/a7f5c638/attachment-0001.htm>

From bibliwho at gmail.com  Fri Apr 29 16:43:33 2022
From: bibliwho at gmail.com (Cab Vinton)
Date: Fri, 29 Apr 2022 10:43:33 -0400
Subject: [Koha-devel] Adding recent (current/past year) statistics to
 the items table
In-Reply-To: <3f99f9f6-76ce-a0a5-51fd-f7e14d0954a1@web.de>
References: <CAA_eX3NMs0Gx+2z_xYWvmy_3zq_5vJsnkmTS5RG68LCNxmNDmg@mail.gmail.com>
 <CAAh7Ud=He2POBaBaULMF7OwGsM5v6n7H7-cK86fxFnZSmiK-fQ@mail.gmail.com>
 <3f99f9f6-76ce-a0a5-51fd-f7e14d0954a1@web.de>
Message-ID: <CABW43UTk4QqhvS=arWau3s4j1CbM5__z=ugjk_juzLRewDYiRQ@mail.gmail.com>

As a librarian I have to agree with Alvaro's comment. With so many Koha
libraries out there, I can easily see there being lots of requests to have
the data parsed just so.

That said, if the request really is for something as simple as YTD
checkouts (+/- renewals), then perhaps this could be added to the Reports
page (reports-home.pl), joining the Item type count report, etc.

Preferable in my view would be some kind of basic dashboard functionality.
I know there are 3rd party options for this (for example
<https://bywatersolutions.com/education/dazzling-dashboard-display-data>),
but librarians are lazy & a native solution is more likely to be used :-)

Just one librarian's opinion ...

Cab Vinton, Director
Plaistow Public Library
Plaistow, NH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220429/fd8604ad/attachment.htm>

From fridolin.somers at biblibre.com  Sat Apr 30 06:18:49 2022
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Fri, 29 Apr 2022 18:18:49 -1000
Subject: [Koha-devel] Koha 22.05 release dates
In-Reply-To: <6b7e68f4-ac54-a602-3f8a-74e9794b9968@biblibre.com>
References: <6b7e68f4-ac54-a602-3f8a-74e9794b9968@biblibre.com>
Message-ID: <9cf9f9f7-18ab-aef2-acd1-d4a1c31f6133@biblibre.com>

Hi

Le 11/04/2022 à 23:23, Fridolin SOMERS a écrit :
> Hi dear community,
> 
> Here is the timeline for the 22.05 major release:
> 
> * April 29 - "Soft" feature freeze : nothing big or with high risk of
> side-effects will be included into the final release if not marked as
> Passed QA
Here we are.
Tell me if there is anything I missed.

> * Mai 6 - "Hard" feature freeze : nothing considered as an
> improvement will be pushed if not marked as Passed QA
> * Mai 11 - String freeze : draft of release notes published
> * Mai 18 - Beta : Only bug fixes considered major, critical or blocker
> will be pushed
> * Mai 26 - Final release
> 
> Let me know if you have any request ;)
> 

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