Re: [Koha-devel] ChatGPT and Koha
Hi David, FWIW, a couple of weeks ago I copied and pasted two snippets of Perl code from Koha because I couldn't understand what type of variable they were generating. ChatGPT came back with a pretty comprehensive answer about hash references. What impressed me (apart from the quality of its reply) was that I copied/pasted the code in a hurry including the line numbers preceding each line, however that did not seem to confuse ChatGPT at all! Kind regards, Andreas On 2023-02-22 02:53, David Cook wrote: Hi all, Like many around the world, I may have been bitten by the ChatGPT bug… Most of my ChatGPT questions have been more general in nature, but I figured I’d ask it about Koha, as there is a lot of public information, but it’s still a niche topic. I asked it to generate me a Koha plugin, and it refused for a while, but eventually I was able to convince it to try. The result wouldn’t even compile, but it got a lot of things right. In other conversations, it’s made mistakes but always done a good job of fixing its mistakes. Has anyone else played with ChatGPT and Koha or ChatGPT in general (on IT topics)? 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@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website :https://www.koha-community.org/ git :https://git.koha-community.org/ bugs :https://bugs.koha-community.org/___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
Re: [Koha-devel] pull latest koha-testing-docker-images (Add new lib directory)
Thanks, Jonathan. In our case, in addition to editing the Apache config file we also had to adjust PERL5LIB in koha-functions.sh (I'm guessing because our gitified Koha instances had Plack enabled). Kind regards, Andreas On 2021-06-24 16:57, Jonathan Druart wrote: (This is a message from last week that didn't reach the list) Hi, I've just pushed bug 28489 that is adding a new "lib" directory. It needs to be added to the apache config, and new koha-testing-docker images have been published. The error: couldn't load CGI::Session::Serialize::yamlxs: Can't locate CGI/Session/Serialize/yamlxs.pm in @INC (you may need to install the CGI::Session::Serialize::yamlxs module) The KTD solution: `docker-compose pull` A workaround (if you are not using ktd): In your apache config, add the lib directory: SetEnv PERL5LIB "/kohadevbox/koha:/kohadevbox/koha/lib" That's not enough, for the CLI scripts (and tests), you will need to adjust PERL5LIB as well In koha-testing-docker, edit .env and replace the PERL5LIB line with: PERL5LIB=/kohadevbox/koha:/kohadevbox/koha/lib:/kohadevbox/qa-test-tools Cheers, Jonathan ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/ ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
Re: [Koha-devel] XSLT to display keywords with 650$2 = x
Hi Magnus, Give the following a try: http://www.loc.gov/MARC21/slim; xmlns:xsl="http://www.w3.org/1999/XSL/Transform;> Regards, Andreas P.S.: There's probably a much better way of doing this... ;-) On 2021-03-02 14:22, Magnus Enger wrote: Kia ora! I want to display most keywords as usual, but with an exception for those from the 650 field. Specifically, I want to display only those keywords that has the value "x" or "y" in subfield $2, and hide the other 650-keywords. Any hints on how to this in XSLT would be infinitely appreciated, and added to the wiki, so others can benefit from the solution. Here is an example: A x B y C z D I want to display A and B (because they have $2 = x or y), and D (because it is not 650), but not C (because it is 650 and $2 is neither x nor y). Best regards, Magnus Libriotech ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/ ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
[Koha-devel] Should we back up /usr/share/koha on a daily basis as well?
Dear Developers, In a standard package installation, the backup tarballs taken by the `koha-common` daily cron job (which calls `koha-run-backups`, which in turn calls `koha-dump` for each Koha instance) do not include the default base directory (i.e. /usr/share/koha). Indeed, including the entire /usr/share/koha tree in every instance's backup tarball (for multi-tenant setups) would be superfluous (not to mention space-consuming). However, I think that some provision should be made so that a backup of the /usr/share/koha tree is taken on a daily basis. This could be kept at the top-level /var/spool/koha/ directory with a filename like common--MM-DD.tar.gz or shared--MM-DD.tar.gz. It should even be possible to pass the base directory path as an argument, in case it has been changed from the default. My reasoning behind this is that people often make local changes to the Koha codebase, or edit the Intranet/OPAC XSLTs, or adjust the Template Toolkit files to account for their needs. So it would be in the users' best interest to have Koha take regular backups of these files as well. Thoughts? Kind regards, Andreas ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] Cover image 'thumbnail' size is bigger than 'imagefile' size
Hi Paul, Jonathan, Thank you both for your prompt replies and your feedback. I have now opened a new bug report here: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21987 Andreas On Wed, 12 Dec 2018 at 14:53, Paul Poulain wrote: > Hi Andreas, > > (and if you can't provide a patch, please file a bug on buzilla, this > description is perfect ! ) > > Le 12/12/2018 à 13:49, Jonathan Druart a écrit : > > Hi Andreas, > > > > This module has never been enhanced much and as you noticed there is > > room for such enhancements :) > > All of what you describe in your email makes sense to me, and I am > > sure the changes will be accepted if a patch is provided. > > > > Cheers, > > Jonathan > > Le mer. 12 déc. 2018 à 06:42, Andreas Roussos a > écrit : > >> Dear Developers, > >> > >> We use local cover images in our setup, and also resize the covers > >> we scan to a width of 160px before uploading and attaching them to > >> a Koha bibliographic record (we upload one cover per biblio). > >> > >> While using phpMyAdmin to view the contents of the 'biblioimages' > >> table (relevant screenshot here: https://imgur.com/a/cSEVLBI), we > >> noticed that the size of the BLOBs for the 'thumbnail' column was in > >> some cases twice as big as that of the 'imagefile' column. In fact, > >> this happens for more than 50% of uploaded covers as you can see > >> from the output of the SQL queries below: > >> > >> mysql> SELECT COUNT( * ) AS count > >> FROM biblioimages > >> WHERE LENGTH( thumbnail ) > ( LENGTH( imagefile ) * 2 ) ; > >> +---+ > >> | count | > >> +---+ > >> | 1356 | > >> +---+ > >> > >> mysql> SELECT COUNT( * ) AS count, > >>SUM( LENGTH( imagefile ) ) AS images_size, > >>SUM( LENGTH( thumbnail ) ) AS thumbnails_size > >> FROM biblioimages ; > >> +---+-+-+ > >> | count | images_size | thumbnails_size | > >> +---+-+-+ > >> | 2347 |68323933 | 115839686 | > >> +---+-+-+ > >> > >> It would appear that for each 160px-wide JPG with 24-bit depth that > >> we have uploaded, the 'imagefile' column has been populated with an > >> PNG of 8 bit depth with the same dimensions as the uploaded file, > >> whereas the 'thumbnail' column contains a 24-bit PNG image with a > >> width reduced to 140 pixels. > >> > >> I've tracked down the creation of resized 24-bit PNGs to this code: > >> > https://github.com/Koha-Community/Koha/blob/master/C4/Images.pm#L182-L183 > >> > >> Do thumbnails for covers need to be true colour (24-bit) images? > >> > >> Also, why is it that _scale_image() returns an image of 8-bit depth > >> if the source image's dimensions are less than 600x800? (i.e. when > >> no resizing is performed) > >> > >> Thank you in advance for your time. > >> > >> Kind regards, > >> Andreas > >> ___ > >> Koha-devel mailing list > >> Koha-devel@lists.koha-community.org > >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > >> website : http://www.koha-community.org/ > >> git : http://git.koha-community.org/ > >> bugs : http://bugs.koha-community.org/ > > ___ > > Koha-devel mailing list > > Koha-devel@lists.koha-community.org > > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > > website : http://www.koha-community.org/ > > git : http://git.koha-community.org/ > > bugs : http://bugs.koha-community.org/ > > -- > Paul Poulain, Associé-gérant / co-owner > BibLibre, Services en logiciels libres pour les bibliothèques > BibLibre, Open Source software and services for libraries > > ___ > Koha-devel mailing list > Koha-devel@lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-devel] Cover image 'thumbnail' size is bigger than 'imagefile' size
Dear Developers, We use local cover images in our setup, and also resize the covers we scan to a width of 160px before uploading and attaching them to a Koha bibliographic record (we upload one cover per biblio). While using phpMyAdmin to view the contents of the 'biblioimages' table (relevant screenshot here: https://imgur.com/a/cSEVLBI), we noticed that the size of the BLOBs for the 'thumbnail' column was in some cases twice as big as that of the 'imagefile' column. In fact, this happens for more than 50% of uploaded covers as you can see from the output of the SQL queries below: mysql> SELECT COUNT( * ) AS count FROM biblioimages WHERE LENGTH( thumbnail ) > ( LENGTH( imagefile ) * 2 ) ; +---+ | count | +---+ | 1356 | +---+ mysql> SELECT COUNT( * ) AS count, SUM( LENGTH( imagefile ) ) AS images_size, SUM( LENGTH( thumbnail ) ) AS thumbnails_size FROM biblioimages ; +---+-+-+ | count | images_size | thumbnails_size | +---+-+-+ | 2347 |68323933 | 115839686 | +---+-+-+ It would appear that for each 160px-wide JPG with 24-bit depth that we have uploaded, the 'imagefile' column has been populated with an PNG of 8 bit depth with the same dimensions as the uploaded file, whereas the 'thumbnail' column contains a 24-bit PNG image with a width reduced to 140 pixels. I've tracked down the creation of resized 24-bit PNGs to this code: https://github.com/Koha-Community/Koha/blob/master/C4/Images.pm#L182-L183 Do thumbnails for covers need to be true colour (24-bit) images? Also, why is it that _scale_image() returns an image of 8-bit depth if the source image's dimensions are less than 600x800? (i.e. when no resizing is performed) Thank you in advance for your time. Kind regards, Andreas ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] Staff/OPAC ISBD views and subfield visibility
Hi Katrin,
As far as our library is concerned we would not want the users to see in
marc view an internal numerical code, which could be puzzling and
confusing, especially if they are looking at personal name entries, who are
usually followed by a role code in unimarc, e.g. 070 for author.
Furthermore, why is the code looking for these values "if hidden" only in
the opac interface? Why is such requirement only for opac isbd – why not
for intranet isbd also, if at all necessary?
Sorry for insisting, but we would like to know the usefulness and reasoning
behind this.
Regards,
Andreas
On 21 June 2018 at 09:11, Katrin Fischer wrote:
> Hi Andreas,
>
> makes sense for me. Why not mark them as visible in the OPAC?
>
> Katrin
>
> On 20.06.2018 09:51, Andreas Roussos wrote:
>
> Hi Katrin,
>
> Thank you for your reply.
>
> The issue we are facing is this: unless a subfield (e.g. UNIMARC 453$0,
> Bibliographic Record Identifier) is marked as visible in the OPAC, the
> links (URLs) using that subfield will be broken in the ISBD view.
> And this happens (according to the code snippets in my original message)
> only when GetISBDView is called with 'template' = 'opac', not 'intranet'
> (i.e. only in OPAC ISBD view, not in Staff ISBD view).
>
> I hope this makes more sense.
>
> Regards,
> Andreas
>
> On 18 June 2018 at 23:22, Katrin Fischer wrote:
>
>> Hi Andreas,
>>
>> I might be misunderstanding your question, but the OPAC visibility
>> setting should take effect on all pages and views in the OPAC now. It
>> didn't use to, which was considered a long standing bug and finally fixed.
>> Now it's possible to hide fields from OPAC that can still appear in staff
>> in a reliable way. The preconfigured visibility settings in the frameworks
>> might not always be ideal - if that's what you mean, we could work on
>> improving them.
>>
>> Hope that helps,
>>
>> Katrin
>>
>>
>> On 07.06.2018 09:21, Andreas Roussos wrote:
>>
>> Dear Developers,
>>
>> If you:
>>
>> 1) edit the ISBD and OPACISBD system preferences so that they contain the
>> following code:
>>
>> #453| - translated as: |http://detail.pl?biblionumber=%7B4530%7D>">{453t}
>> {(453d)}|
>> #454| - translation of: |http://detail.pl?biblionumber=%7B4540%7D>">{454t}
>> {(454d)}|
>>
>> 2) set the visibility of (UNIMARC) fields 453$0 and 454$0 to 'hidden' in
>> the OPAC
>>
>> ...then the generated links will work fine in the Staff client but will
>> be broken in the OPAC (i.e. the URL will not include the biblionumber
>> contained in subfield 0 of fields 453/454).
>>
>> I've tracked this down to ISBDdetail.pl and opac-ISBDdetail.pl calling
>> the GetISBDView subroutine, which (for some reason) excludes subfields that
>> are hidden in the OPAC:
>>
>> https://github.com/Koha-Community/Koha/blob/master/C4/Biblio.pm#L773-L776
>> https://github.com/Koha-Community/Koha/blob/master/C4/Biblio.pm#L812-L815
>>
>> What is the reasoning behind this?
>> In other words, why is _OPAC_ subfield visibility taken into account when
>> displaying the OPAC ISBD view (whereas visibility in Staff is not
>> considered)?
>>
>> If anything, it is more likely to have subfield 0 hidden in OPAC, while
>> visible in Staff, so one would expect the opposite logic.
>>
>> Thanks in advance for your time.
>>
>> Kind regards,
>> Andreas Roussos
>>
>>
>> ___
>> Koha-devel mailing
>> listkoha-de...@lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>>
>>
>>
>> ___
>> Koha-devel mailing list
>> Koha-devel@lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>>
>
>
>
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Re: [Koha-devel] Staff/OPAC ISBD views and subfield visibility
Hi Katrin,
Thank you for your reply.
The issue we are facing is this: unless a subfield (e.g. UNIMARC 453$0,
Bibliographic Record Identifier) is marked as visible in the OPAC, the
links (URLs) using that subfield will be broken in the ISBD view.
And this happens (according to the code snippets in my original message)
only when GetISBDView is called with 'template' = 'opac', not 'intranet'
(i.e. only in OPAC ISBD view, not in Staff ISBD view).
I hope this makes more sense.
Regards,
Andreas
On 18 June 2018 at 23:22, Katrin Fischer wrote:
> Hi Andreas,
>
> I might be misunderstanding your question, but the OPAC visibility setting
> should take effect on all pages and views in the OPAC now. It didn't use
> to, which was considered a long standing bug and finally fixed. Now it's
> possible to hide fields from OPAC that can still appear in staff in a
> reliable way. The preconfigured visibility settings in the frameworks might
> not always be ideal - if that's what you mean, we could work on improving
> them.
>
> Hope that helps,
>
> Katrin
>
>
> On 07.06.2018 09:21, Andreas Roussos wrote:
>
> Dear Developers,
>
> If you:
>
> 1) edit the ISBD and OPACISBD system preferences so that they contain the
> following code:
>
> #453| - translated as: |http://detail.pl?biblionumber=%7B4530%7D>">{453t}
> {(453d)}|
> #454| - translation of: |http://detail.pl?biblionumber=%7B4540%7D>">{454t}
> {(454d)}|
>
> 2) set the visibility of (UNIMARC) fields 453$0 and 454$0 to 'hidden' in
> the OPAC
>
> ...then the generated links will work fine in the Staff client but will be
> broken in the OPAC (i.e. the URL will not include the biblionumber
> contained in subfield 0 of fields 453/454).
>
> I've tracked this down to ISBDdetail.pl and opac-ISBDdetail.pl calling the
> GetISBDView subroutine, which (for some reason) excludes subfields that are
> hidden in the OPAC:
>
> https://github.com/Koha-Community/Koha/blob/master/C4/Biblio.pm#L773-L776
> https://github.com/Koha-Community/Koha/blob/master/C4/Biblio.pm#L812-L815
>
> What is the reasoning behind this?
> In other words, why is _OPAC_ subfield visibility taken into account when
> displaying the OPAC ISBD view (whereas visibility in Staff is not
> considered)?
>
> If anything, it is more likely to have subfield 0 hidden in OPAC, while
> visible in Staff, so one would expect the opposite logic.
>
> Thanks in advance for your time.
>
> Kind regards,
> Andreas Roussos
>
>
> ___
> Koha-devel mailing
> listkoha-de...@lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
>
>
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
[Koha-devel] Staff/OPAC ISBD views and subfield visibility
Dear Developers,
If you:
1) edit the ISBD and OPACISBD system preferences so that they contain the
following code:
#453| - translated as: |{453t} {(453d)}|
#454| - translation of: |{454t} {(454d)}|
2) set the visibility of (UNIMARC) fields 453$0 and 454$0 to 'hidden' in
the OPAC
...then the generated links will work fine in the Staff client but will be
broken in the OPAC (i.e. the URL will not include the biblionumber
contained in subfield 0 of fields 453/454).
I've tracked this down to ISBDdetail.pl and opac-ISBDdetail.pl calling the
GetISBDView subroutine, which (for some reason) excludes subfields that are
hidden in the OPAC:
https://github.com/Koha-Community/Koha/blob/master/C4/Biblio.pm#L773-L776
https://github.com/Koha-Community/Koha/blob/master/C4/Biblio.pm#L812-L815
What is the reasoning behind this?
In other words, why is _OPAC_ subfield visibility taken into account when
displaying the OPAC ISBD view (whereas visibility in Staff is not
considered)?
If anything, it is more likely to have subfield 0 hidden in OPAC, while
visible in Staff, so one would expect the opposite logic.
Thanks in advance for your time.
Kind regards,
Andreas Roussos
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
[Koha-devel] Bug 17278 - reverted for 16.05.x only - why?
Dear Devs, Re: Bug 17278 - Limit to available items returns 0 results We're running Koha 16.05.16 on Debian and are affected by this bug. AFAICT there were a couple of patches written for this, which were pushed to the master/16.05.x/3.22.x branches. However, the commits for 16.05.x were later reverted: http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=aed6d17ffd3aa6de49deb9dab9436ba979c35f6e http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=4f761bb6904b127990b8d1e993ea67098f8cdb7c I've searched the koha-bugs and koha-devel mailing lists and also peeked at the IRC logs for the #koha channel but could not find a reference as to why these commits were reverted for 16.05.x only. Does anyone recall why these changes were reverted for 16.05 only? Thanks for your time. Regards, Andreas Roussos ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
