[Koha-devel] Bug 33092 - Add ability to search within a list
Hi all, Has anyone looked at this one? My first thought is that the list ID would need to be added to a repeatable subfield (e.g. 999$l) and indexed. That way it would be easy to allow any search engine query and then just wrap it like "() and (list_id=X)". But. it would mean that we'd have to re-index records for list operations, and I don't love that. Does anyone have any other ideas? Or happy to support this one? It would be a fairly significant change to lists, so I think it would need to be well thought out. 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/
Re: [Koha-devel] Google OpenID Connect
The Google OpenID Connect specific functionality only targeted the OPAC. Probably because it’s the most common use case. (I wrote my own OpenID Connect integration for Koha about 10 years ago, and it only targeted the OPAC too.) However, Koha has a different more generic Oauth2/OpenID Connect feature that targets both the OPAC and the staff interface. It should be usable with Google as well, if you want to target it. I think at some point the Google OpenID Connect specific code will be removed from Koha. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of long_sam.tw via Koha-devel Sent: Thursday, 18 April 2024 7:22 AM To: koha-devel Subject: [Koha-devel] Google OpenID Connect Hi, all Google OpenID Connect is used in koha. Why does opac have this identity authentication login, but staff does not have this function? What is the main reason? With respect, long_sam ___ 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] SelfCheckoutByLogin
Hi long_sam, Thanks for your reply. You’re right; SAML does have single log out functionality. However, from my understanding it’s a “front-channel logout” mechanism that requires the redirecting of the user in the browser. With OpenID Connect, the “back-channel logout” is a request sent from the server to the IdP without needing to redirect the user in the browser. As far as I know, SAML doesn’t have “back-channel logout” functionality. That being said, I suppose there’s no reason you couldn’t do a front-channel logout. In fact, that might be preferable, because then the user would know that they’ve been logged out of the Identity Provider (or that there was some failure to logout, so they could take manual steps to end their SSO session). -- I like the idea of being able to use credentials from a centralized Identity Provider to log into the self-checkout, but personally I wouldn’t want to use SSO on a shared system that could potentially leave my SSO session open beyond my interactions with the self-checkout. And I’m a tech-savvy user. I fear for users who are not tech-savvy. Another technical detail. At the moment, Koha is set up to allow SAML or OpenID Connect for creating authenticated user sessions. In the case of the self-checkout, the actual user session belongs to a self-checkout user. When you put in your cardnumber or username/password, you’re not actually creating a new user session. You’re really just authorizing the self-checkout user to work with your account. So the existing code for the SAML/OpenID Connect can’t be easily re-used I think. We’d need totally different implementations just for the self-checkout. (I suppose one option would be to allow SSO login, confirm the authenticated session, and then immediately do a SLO (single log out) from the IdP to help reduce the time the SSO session exists.) -- So overall… there are ways of doing it. A few of us discussed it at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30444 but ultimately no one decided to pursue it. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30979 provided a method for allowing OPAC users to checkout to themselves, so you’d login as the OPAC user (using SSO) and then checkout to yourself. I think the idea here is that you do it on a private device though. 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: long_sam.tw Sent: Monday, 15 April 2024 10:45 PM To: koha-devel@lists.koha-community.org; David Cook Subject: Re: [Koha-devel] SelfCheckoutByLogin Hi, David I found the AWS SAML SSO logout example. SAML sign-out flow - Amazon Cognito <https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-saml-idp-sign-out.html> SAML SSO logout IDP, security issues. When logging out of a SAML SSO IDP (Identity Provider), there are several security considerations to keep in mind: 1. Single Logout (SLO) Support: Ensure that your IDP supports Single Logout functionality, which logs the user out from all related Service Providers (SPs) when they log out from one, maintaining session consistency and security. 2. Logout Request Validation: When the IDP receives a logout request from an SP, it must validate the request to prevent malicious requests or Cross-Site Request Forgery (CSRF) attacks. Validation can be achieved through digital signatures or other secure mechanisms. 3. Security of Callback URLs: Ensure that the callback URLs used during logout are secure, avoiding the use of vulnerable or unauthorized URLs. 4. Session Management: Ensure that the IDP correctly terminates relevant sessions and clears user authentication information and session data upon logout to prevent session hijacking or replay attacks. 5. Security Event Monitoring: Establish monitoring mechanisms for logout operations and related session management events to promptly detect abnormal behavior or security incidents and take necessary response measures. 6. Security Auditing and Logging: Conduct thorough auditing and logging of logout operations and related security events to facilitate audit investigations or security incident tracing when needed. 7. Integration with Other Security Mechanisms: Integrate the logout functionality of SAML SSO with other security mechanisms such as Multi-Factor Authentication (MFA), Access Control Lists (ACLs), etc., to enhance the overall security of the system. 8. Regular Security Assessments: Conduct regular security assessments and vulnerability scans of the SAML SSO logout process, and promptly address any identified security issues to ensure the security and stability of the system. In summary, logging out of a SAML SSO IDP requires attention to ensuring Single Logout support, secure logout request validation, security of ca
Re: [Koha-devel] SelfCheckoutByLogin
Part of the reason is that it’s considerably more complicated and error-prone. If you log in using Google OpenID Connect, the self-checkout browser will retain your Google user session beyond your Koha self-checkout user session. Also, when Koha goes back to Google to authenticate someone else, it will auto-detect that you’re still logged in, and use your account instead. In theory, we could do a back channel logout against Google (or whatever other OpenID Connect identity provider), but if that failed to run for whatever reason you’re risking someone else at a public terminal accessing your personal Google account. SAML doesn’t even have options for back channel logout, which makes it not an option at all. If someone can think of a really good way of making this work, I’d be happy to discuss it further, but I can’t think of a safe way to do this on a public terminal at the moment. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Katrin Fischer via Koha-devel Sent: Monday, 15 April 2024 6:29 AM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] SelfCheckoutByLogin Hi, I think there is probably no specific reason, it's just not been developed yet. As a next step you could search Bugzilla (https://bugs.koha-community.org/bugzilla3/) for any related bugs. If there is no existing report yet, you could file a new enhancement request. Hope this helps, Katrin On 12.04.24 23:49, long_sam.tw via Koha-devel wrote: Hi, all Koha SelfCheckoutByLogin https://koha-community.org/manual/latest/en/html/circulationpreferences.html#selfcheckoutbylogin I found that only local account authentication and cardnumber are supported, but other authentication methods are not supported, such as google openid Oauth2, are not supported. Can anyone explain the reason? With respect, long_sam ___ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : 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] Finding invalid XML characters in Koha data via SQL
I’m just finishing up the next version of the plugin which finds problem bib records, problem item records, and lets you fix 1 bib record and its X problem item records at a time. I’ll be putting it up online sometime in the next couple weeks. (I’m away a lot these couple of weeks, so tough to give a firm time.) But I’m about to use it to find problem item records in one of my systems… 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 Sent: Sunday, 14 April 2024 2:49 AM To: Magnus Enger Cc: David Cook ; koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Finding invalid XML characters in Koha data via SQL Yeah, dump it somewhere and we send pull requests to add missing bits El El vie, 12 abr 2024 a la(s) 9:50 a. m., Magnus Enger via Koha-devel mailto:koha-devel@lists.koha-community.org> > escribió: Den 12.04.2024 08:24, skrev David Cook: > Not yet. At some point I need to get better at sharing Koha plugins more > widely. Just dump it to Github or similar, and set the version to 0.0.1. ;-) Release early, release often. Best regards, Magnus ___ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/ ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
Re: [Koha-devel] [Koha] Error 500 when searching in Koha 23.11.0
Hi Michael, I don't think your database was properly upgraded, and doing these manual corrections isn't really going to be enough unless you go line by line through the upgrade scripts and figure out all the things that were missed. If you're able to, I would go back and try the upgrade again. If you can't... then I would carefully look through every database revision. You might also want to consider looking at ./misc/maintenance/audit_database.pl as that could save you time. (Just don't blindly run the suggestions made by the script. They're just hints.) 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 On Behalf Of Michael Kuhn via Koha-devel Sent: Saturday, 13 April 2024 9:28 AM To: k...@lists.katipo.co.nz; Koha-devel Subject: Re: [Koha-devel] [Koha] Error 500 when searching in Koha 23.11.0 Hi Just for the record: I updated from Koha 21.11.10 to 23.11.04. When searching the catalogue I got a result list, but when clicking a single hit I got an error 500. In file "plack-error.log" I found this: DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Unknown column 'issue.renewals_count' in 'field list' at /usr/share/koha/lib/Koha/Objects.pm line 317 In Koha 21.11 this column was called "issues.renewals" and in Koha 23.11 it should be called "issues.renewals_count" - but for whatever reason the upgrade did not rename it properly. I have done that myself: ALTER TABLE issues RENAME COLUMN renewals TO renewals_count; Now single hits show up. PS1: The error message says the column is "issue.renewals_count" but actually it is "issues.renewals_count". PS2: https://schema.koha-community.org/23_11/tables/issues.html says the type of this column is tinyint(3) while it actually is tinyint(4). Best wishes: Michael -- Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz T 0041 (0)61 261 55 61 · E m...@adminkuhn.ch · W www.adminkuhn.ch ___ 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] Finding invalid XML characters in Koha data via SQL
Not yet. At some point I need to get better at sharing Koha plugins more widely. 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 On Behalf Of Magnus Enger via Koha-devel Sent: Friday, 12 April 2024 4:09 PM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Finding invalid XML characters in Koha data via SQL Den 12.04.2024 04:13, skrev David Cook via Koha-devel: > I have a RepairRecord plugin, so I might do a version in that first, > and if that goes well I could look at upstreaming a patch… Intriguing! :-) Is it available somewhere? Best regards, Magnus ___ 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] Finding invalid XML characters in Koha data via SQL
Yeah, I was thinking it would be good to add to the SQL Report Library. I've
just been flat out today... (but wanted to make sure I shared it with you folk
at least)
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 On Behalf Of
Magnus Enger via Koha-devel
Sent: Friday, 12 April 2024 4:06 PM
To: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] Finding invalid XML characters in Koha data via SQL
Hi!
Den 12.04.2024 03:36, skrev David Cook via Koha-devel:
> Hi all,
>
> I just wanted to share a (MariaDB) SQL report that I wrote for finding
> bib records with invalid XML characters:
>
> select biblionumber from biblio_metadata where metadata REGEXP
> '[^\\x{0009}\\x{000A}\\x{000D}\\x{0020}-\\x{D7FF}\\x{E000}-\\x{FFFD}\\
> x{1}-\\x{10}]+';
>
> Newer versions of Koha strip invalid character from the XML so that
> you can fix your records. I figure this report is very valuable when
> coupled with that functionality. In fact, I just advised a library
> today to use them together to fix up some bad data in their catalogue.
>
> --
>
> On a related note, I’ve noticed that you can have a record with good
> bib XML but invalid item XML, and you won’t notice until your record
> fails to be indexed. So I’m planning on writing a report for that too.
>
> I’m thinking it might be good to add these reports to core Koha, so
> that people can find and fix their own metadata problems. What do people
> think?
Sounds like an excellent idea! Sounds kind of similar to "MARC bibliographic
framework test" at /cgi-bin/koha/admin/checkmarc.pl
The report could also be added to
https://wiki.koha-community.org/wiki/SQL_Reports_Library for older Kohas and to
be immediately useful.
Best regards,
Magnus
___
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] Bug 36586 - Self-checkouts will get CSRF errors if left inactive for 8 hours
Hi all, We recently noticed that self-checkouts will generate CSRF errors when left unattended for over 8 hours (the lifetime of the CSRF token). Our solution is to use a timer to refresh the page every 8 hours or so, but open to other ideas. This will potentially affect Vue.js driven pages that don't reload the whole page. Although maybe Jonathan has already come up with a solution for that. I'm not sure. 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/
Re: [Koha-devel] Finding invalid XML characters in Koha data via SQL
Alas, I couldn't think of a really clever way of doing the items table, so I
think it'll need a Perl-based solution.
I have a RepairRecord plugin, so I might do a version in that first, and if
that goes well I could look at upstreaming a patch.
David Cook
Senior Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
From: Koha-devel On Behalf Of
David Cook via Koha-devel
Sent: Friday, 12 April 2024 11:36 AM
To: 'Koha-devel'
Subject: [Koha-devel] Finding invalid XML characters in Koha data via SQL
Hi all,
I just wanted to share a (MariaDB) SQL report that I wrote for finding bib
records with invalid XML characters:
select biblionumber from biblio_metadata where metadata REGEXP
'[^\\x{0009}\\x{000A}\\x{000D}\\x{0020}-\\x{D7FF}\\x{E000}-\\x{FFFD}\\x{1000
0}-\\x{10}]+';
Newer versions of Koha strip invalid character from the XML so that you can
fix your records. I figure this report is very valuable when coupled with
that functionality. In fact, I just advised a library today to use them
together to fix up some bad data in their catalogue.
--
On a related note, I've noticed that you can have a record with good bib XML
but invalid item XML, and you won't notice until your record fails to be
indexed. So I'm planning on writing a report for that too.
I'm thinking it might be good to add these reports to core Koha, so that
people can find and fix their own metadata problems. What do people think?
David Cook
Senior Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
___
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] Finding invalid XML characters in Koha data via SQL
Hi all,
I just wanted to share a (MariaDB) SQL report that I wrote for finding bib
records with invalid XML characters:
select biblionumber from biblio_metadata where metadata REGEXP
'[^\\x{0009}\\x{000A}\\x{000D}\\x{0020}-\\x{D7FF}\\x{E000}-\\x{FFFD}\\x{1000
0}-\\x{10}]+';
Newer versions of Koha strip invalid character from the XML so that you can
fix your records. I figure this report is very valuable when coupled with
that functionality. In fact, I just advised a library today to use them
together to fix up some bad data in their catalogue.
--
On a related note, I've noticed that you can have a record with good bib XML
but invalid item XML, and you won't notice until your record fails to be
indexed. So I'm planning on writing a report for that too.
I'm thinking it might be good to add these reports to core Koha, so that
people can find and fix their own metadata problems. What do people think?
David Cook
Senior Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
___
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] Update to Koha 23.11.04 fails
Hi Michael,
I've noticed that a bunch of the database changes for the additional_contents
table can half-complete and not fatally fail in very ungraceful ways.
In this case, I'd say an earlier update probably failed to rename "idnew" to
"id".
Hopefully this was a test upgrade, because otherwise you're going to have pain
trying to fix it...
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 On Behalf Of
Michael Kuhn via Koha-devel
Sent: Friday, 12 April 2024 7:14 AM
To: Koha-devel
Subject: [Koha-devel] Update to Koha 23.11.04 fails
Hi
Today I tried to update a Koha 21.11.10 database to Koha 23.11.04 but the
update process failed at the following point:
Upgrade to 23.06.00.068 [22:55:59]: Bug 23798 - Convert OpacMaintenanceNotice
system preference to additional contents ERROR - {UNKNOWN}: DBI Exception:
DBD::mysql::db selectrow_array failed:
Unknown column 'id' in 'field list' at
/usr/share/koha/lib/C4/Installer.pm line 741
I couldn't find anything regarding this error in Bugzilla, but maybe it is
related to
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23798#c12
which shows a similar error regarding an "Unknown column 'title'".
How should I proceed?
Best wishes: Michael
--
Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis Admin
Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz T 0041 (0)61 261 55 61
· E m...@adminkuhn.ch · W www.adminkuhn.ch
___
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] XZ Utils backdoor for Linux
Hi all, This isn't related to Koha per se, but I thought I'd share it for anyone who hasn't seen it: https://en.wikipedia.org/wiki/XZ_Utils_backdoor All the more reason to have things like Kohacon so that we actually know each other. 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/
Re: [Koha-devel] Elasticsearch sans Zebra
Can you be more specific? If there’s a problem, a ticket should be raised. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Philippe Blouin via Koha-devel Sent: Wednesday, 27 March 2024 11:30 PM To: Fridolin SOMERS ; koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Elasticsearch sans Zebra Well, not really. Hammat asked about limitations on Feb 28 on this very list, because attributes are not well handled. <https://inlibro.com/> Philippe Blouin Directeur de la technologie T833-INLIBRO (465-4276), poste 230 C <mailto:philippe.blo...@inlibro.com> philippe.blo...@inlibro.com <https://inLibro.com> www.inLibro.com On 2024-03-27 06:21, Fridolin SOMERS via Koha-devel wrote: Ah nope, z39.50 can be handled by misc/z3950_responder.pl https://wiki.koha-community.org/wiki/Setting_up_the_Z39.50_and_SRU_Server Le 25/03/2024 à 13:59, Philippe Blouin a écrit : Hi! We have a scenario (albeit an exception) where both are used, due to the limitation of ES's z3950. So we fill zebraqueue uselessly in 199 Koha, but really really need it in 1. Logo inLibro <https://inLibro.com> <https://inLibro.com> Philippe Blouin Directeur de la technologie T 833-INLIBRO (465-4276) , poste 230 C philippe.blo...@inlibro.com <mailto:philippe.blo...@inlibro.com> www.inLibro.com <http://www.inLibro.com> <https://inLibro.com> <https://inLibro.com> On 2024-03-25 08:54, Fridolin SOMERS via Koha-devel wrote: Hi, We have patch since a few years for that because filling zebraqueue is useless and can't be removed with cleanup_database.pl : https://git.biblibre.com/biblibre/kohac/commit/50ae1a44d200c6fa46940107d15bef6d66e55383 It would be nice to have a more official way ;) Best regards Le 25/03/2024 à 12:29, David Schmidt via Koha-devel a écrit : Hi David the majority of our Koha installations use Elastiscearch and we have a process that deactivates zebra but we would love to see the change you proposed. I vaguely remember a bug where not having zebra running caused a problem (with background jobs i think) even if ES is in charge of indexing. cheers david (HKS3/www.koha-support.eu) On Mon, 25 Mar 2024, at 2:22 AM, David Cook via Koha-devel wrote: Hi all, I have started using Elasticsearch more with Koha, and we’re at a point of wanting to use Elasticsearch without Zebra for Koha. I came across “Bug 21820 - Zebraqueue should not be added to when only Elasticsearch is used” and it seems like other people are interested in this too. I imagine it’s just a case of getting a patch written? Overall, it’s an idea that people support? 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 <mailto:Koha-devel@lists.koha-community.org> <mailto:Koha-devel@lists.koha-community.org> <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel <https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel> <https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel> website : https://www.koha-community.org/ <https://www.koha-community.org/> <https://www.koha-community.org/> git : https://git.koha-community.org/ <https://git.koha-community.org/> <https://git.koha-community.org/> bugs : https://bugs.koha-community.org/ <https://bugs.koha-community.org/> <https://bugs.koha-community.org/> ___ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : 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] Elasticsearch indexing does not handle exceptions well
Hi all, I'm re-indexing Elasticsearch and I notice occasionally Elasticsearch will throw an exception when committing (e.g. Elasticsearch exception thrown: Request), and Koha just ignores it. That means that whole commit gets missed, so a default of 5000 records don't get indexed. You can probably find those inconsistencies using /usr/share/koha/bin/maintenance/compare_es_to_db.pl but that doesn't provide you a method for indexing those missed records either. Am I missing something obvious here? I'll need to look at increasing the verbosity to get more of the error message, and I'll play around with some settings to make it so that the Elasticsearch server doesn't thrown an error, but this seems weird to me. Perhaps we should have an automatic re-try, or at least a record of what records failed to be committed, so that they can be manually retried via a different mechanism? 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] Elasticsearch sans Zebra
Hi all, I have started using Elasticsearch more with Koha, and we're at a point of wanting to use Elasticsearch without Zebra for Koha. I came across "Bug 21820 - Zebraqueue should not be added to when only Elasticsearch is used" and it seems like other people are interested in this too. I imagine it's just a case of getting a patch written? Overall, it's an idea that people support? 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/
Re: [Koha-devel] Random XSLT knowledge
Hi Marcel,
Sure!
Before Koha started using "http://exslt.org/strings; to encode URIs, I used
to use register_function to add my own function to do that.
1. vi C4/XSLT.pm
2. Add a line near the top like:
a.
XML::LibXSLT->register_function("http://.prosentient.com.au/xsltperl;,
"uri-escape",\::Prosentient::Biblio::Urls::xslt_uri_escape);
3. Write a function like this:
sub xslt_uri_escape {
my ($uri) = @_;
#$uri should always be a XML::LibXML::Nodelist, even if that Nodelist
just contains 1 URI
if (ref $uri eq "XML::LibXML::NodeList"){
$uri->foreach(
sub {
my ( $node ) = @_;
#If the node has child (text) nodes
if ($node->hasChildNodes()){
my @childNodes = $node->childNodes();
if (@childNodes){
foreach my $childNode (@childNodes){
if (my $textdata = $childNode->data){
#Trim whitespace
$textdata =~ s/^\s+|\s+$//g;
my $encoded_url =
URI::Encode::uri_encode($textdata, { encode_reserved => 0 });
if ($encoded_url){
#Replace the existing URI data with the
encoded URI data
$childNode->setData($encoded_url);
}
}
}
}
}
}
);
}
return $uri;
}
4. Add the namespace at the top of your XSLT:
a. xmlns:pro="http://.prosentient.com.au/xsltperl;
5. Call the function on some XML:
a.
--
More recently, I've done more complicated things like looking up item urls
for that biblio record, deduplicating them against the 856$u, and adding
them to the online access in the search results. I continue to take into
account OpacHiddenItems and its associated preferences. Since it's operating
at the Perl level, I'm able to check the C4::Context->userenv for the patron
details as well.
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: Marcel de Rooy
Sent: Friday, 8 March 2024 6:13 PM
To: 'Koha Devel' ; David Cook
Subject: Re: [Koha-devel] Random XSLT knowledge
Hi David,
Thanks for sharing.
Would you have an example of how you use register_function with Koha
functions to share?
Marcel
_
Van: Koha-devel mailto:koha-devel-boun...@lists.koha-community.org> > namens David Cook via
Koha-devel mailto:koha-devel@lists.koha-community.org> >
Verzonden: vrijdag 8 maart 2024 03:02
Aan: 'Koha Devel' mailto:koha-devel@lists.koha-community.org> >
Onderwerp: [Koha-devel] Random XSLT knowledge
Hi all,
I've been working on performance issues, and in the process I got looking at
XSLTs.
I just wanted to share that it's possible to pass strings to the XSLT's
transform() method:
-return $engine->transform($xmlrecord, $xslfilename ); #file or URL
+return $engine->transform({
+xml => $xmlrecord,
+file => $xslfilename,
+parameters => {
+test => "'$test_str'",
+},
+}); #file or URL
It's somewhat limited in that you can only pass strings and I think there's
a small limit on the number of parameters you can pass (not sure if it's 32
or 255), but I thought it was interesting. It would allow you to pass some
data that you have at hand on a per-XML record basis without having to
mangle the XML record (like we do with items and system preferences).
In the end, I didn't end up using it though. Instead, I use
XML::LibXSLT->register_function() to provide access to Koha functions from
the XSLT, and in this case that meets my needs.
Anyway, back to it..
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] SMTP servers requiring XOAUTH2
Hey folks, Is anyone using Koha with SMTP servers requiring XOAUTH2? It doesn't look like the Perl libraries used by Koha are anywhere near ready for it, but it looks like Postfix has an experimental plugin available: https://github.com/tarickb/sasl-xoauth2 or https://packages.debian.org/experimental/sasl-xoauth2 I think both Gmail and Microsoft require it these days. 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] Random XSLT knowledge
Hi all,
I've been working on performance issues, and in the process I got looking at
XSLTs.
I just wanted to share that it's possible to pass strings to the XSLT's
transform() method:
-return $engine->transform($xmlrecord, $xslfilename ); #file or URL
+return $engine->transform({
+xml => $xmlrecord,
+file => $xslfilename,
+parameters => {
+test => "'$test_str'",
+},
+}); #file or URL
It's somewhat limited in that you can only pass strings and I think there's
a small limit on the number of parameters you can pass (not sure if it's 32
or 255), but I thought it was interesting. It would allow you to pass some
data that you have at hand on a per-XML record basis without having to
mangle the XML record (like we do with items and system preferences).
In the end, I didn't end up using it though. Instead, I use
XML::LibXSLT->register_function() to provide access to Koha functions from
the XSLT, and in this case that meets my needs.
Anyway, back to it..
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] PatternFly for design?
Hi all, Has anyone used PatternFly for designing? https://www.patternfly.org/ 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] Future of mod_security
Hi all, mod_security has had a troubled existence the past few years, but it looks like the company behind it has transferred it over to OWASP: https://owasp.org/blog/2024/01/09/ModSecurity.html Hopefully this means mod_security starts getting updated more. 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/
Re: [Koha-devel] Override sysprefs in Apache config
Martin, you legend. That’s what I was looking for and missing I think. Thanks for making me feel less crazy : ). 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: Renvoize, Martin Sent: Tuesday, 27 February 2024 9:51 AM To: David Cook Cc: Magnus Enger ; Koha Devel Subject: Re: [Koha-devel] Override sysprefs in Apache config That might be what the _NAMES override is for.. I believe you pass it a list of the Prefs your overriding and it'll then display a message in the sysprefs if the staff client stating their likely override at the virtual host level. On Sun, 18 Feb 2024, 10:21 pm David Cook via Koha-devel, mailto:koha-devel@lists.koha-community.org> > wrote: Hi Magnus, Yeah, I was thinking it wouldn't make sense to affect the staff interface UI, since you might be overriding 5 different OPAC virtual hosts. But I had a vague memory that there was some sort of signifier that the syspref was being overridden. Maybe a false memory in the end. In the end, I did use X-Koha-SetEnv to set a syspref for one of two OPAC virtual hosts, so that worked well enough. 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 mailto:koha-devel-boun...@lists.koha-community.org> > On Behalf Of Magnus Enger via Koha-devel Sent: Friday, 16 February 2024 6:26 PM To: koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Override sysprefs in Apache config Hi! Den 16.02.2024 06:56, skrev David Cook via Koha-devel: > I think it might be partially broken. > > As per https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16520 > <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16520> I > added the following to the OPAC and the staff interface: > > RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_LibraryName Potato\, > Potato" > > It did indeed load into the OPAC. > > In the past, I think it used to fill in and lock the syspref in the > staff interface as well… but maybe not anymore. Maybe because it > would just affect the staff interface, and yet sometimes maybe you > only want to affect the staff interface… hmm… We have used this a fair bit to set up alternative/infividual OPACs for individual libraries, but I have never seen a setting like that fill in or otherwise affect the actual syspref. And how would that work when you have 5 different VirtualHost configs all setting their own OVERRIDE_SYSPREF_LibraryName? I can confirm that settings like these work for us: RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_LibraryName Grundskolan" RequestHeader add X-Koha-SetEnv "OPAC_SEARCH_LIMIT branch:multibranchlimit-23" RequestHeader add X-Koha-SetEnv "OPAC_LIMIT_OVERRIDE 1" Best regards, Magnus ___ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : 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 <mailto: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] DataTables 2.0.0
Hi all, I do not intend to draw your attention to this in any meaningful way. I just wanted to point out that DataTables 2.0.0 was released on February 15th 2024 (https://cdn.datatables.net/2.0.0/). Just squirrel away that information in the back of your brain for later. 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/
Re: [Koha-devel] Override sysprefs in Apache config
Hi Magnus, Yeah, I was thinking it wouldn't make sense to affect the staff interface UI, since you might be overriding 5 different OPAC virtual hosts. But I had a vague memory that there was some sort of signifier that the syspref was being overridden. Maybe a false memory in the end. In the end, I did use X-Koha-SetEnv to set a syspref for one of two OPAC virtual hosts, so that worked well enough. 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 On Behalf Of Magnus Enger via Koha-devel Sent: Friday, 16 February 2024 6:26 PM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Override sysprefs in Apache config Hi! Den 16.02.2024 06:56, skrev David Cook via Koha-devel: > I think it might be partially broken. > > As per https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16520 > <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16520> I > added the following to the OPAC and the staff interface: > > RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_LibraryName Potato\, > Potato" > > It did indeed load into the OPAC. > > In the past, I think it used to fill in and lock the syspref in the > staff interface as well… but maybe not anymore. Maybe because it > would just affect the staff interface, and yet sometimes maybe you > only want to affect the staff interface… hmm… We have used this a fair bit to set up alternative/infividual OPACs for individual libraries, but I have never seen a setting like that fill in or otherwise affect the actual syspref. And how would that work when you have 5 different VirtualHost configs all setting their own OVERRIDE_SYSPREF_LibraryName? I can confirm that settings like these work for us: RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_LibraryName Grundskolan" RequestHeader add X-Koha-SetEnv "OPAC_SEARCH_LIMIT branch:multibranchlimit-23" RequestHeader add X-Koha-SetEnv "OPAC_LIMIT_OVERRIDE 1" Best regards, Magnus ___ 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] Override sysprefs in Apache config
I think it might be partially broken. As per https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16520 I added the following to the OPAC and the staff interface: RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_LibraryName Potato\, Potato" It did indeed load into the OPAC. In the past, I think it used to fill in and lock the syspref in the staff interface as well. but maybe not anymore. Maybe because it would just affect the staff interface, and yet sometimes maybe you only want to affect the staff interface. hmm. 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: David Cook Sent: Friday, 16 February 2024 4:52 PM To: 'koha-devel' Subject: Override sysprefs in Apache config Hi all, I've read this wiki page and tried this many times, and never ever gotten it to work. Is there something missing from these instructions? https://wiki.koha-community.org/wiki/Override_sysprefs_in_Apache_config 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] Override sysprefs in Apache config
Hi all, I've read this wiki page and tried this many times, and never ever gotten it to work. Is there something missing from these instructions? https://wiki.koha-community.org/wiki/Override_sysprefs_in_Apache_config 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] Session corruption in koha-testing-docker master
Hi all, The last two days I've noticed that my session is getting corrupted while I'm working on master in koha-testing-docker. I'm not touching the session myself, but seemingly randomly the session gets all kinds of DIBC data stuffed into it, and Koha seems to be parse it and Koha throws a fatal error, which can only be resolved by deleting the problematic session from the table. Just curious if anyone else is seeing this. I really don't think it's related to anything I'm working on, but I also can't reliably reproduce it. 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/
Re: [Koha-devel] Growing size of koha/koha-testing:master
That's interesting. I think that adds up to about 2.5GB. I wonder where the other 2GB comes from. I have been wondering if we should be doing some of these steps in a "builder" image and copying across files in case some of the bloat is in the layering. Something to play with perhaps. It's not a top priority at the moment, but I thought I'd raise it. A few large koha-testing-docker images start adding up in terms of SDD space. I upgraded workstations not that long ago, and now I'm thinking maybe I need to do it again just for the storage... 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: Victor Grousset/tuxayo Sent: Wednesday, 7 February 2024 1:33 PM To: David Cook Cc: koha-devel Subject: Re: [Koha-devel] Growing size of koha/koha-testing:master On 24-02-04 23:30, David Cook via Koha-devel wrote: > Do we know what’s contributing to this? After running `ncdu /` from inside KTD Debian 10 (the smallest image it seems) - 661 M /kohadevbox/Cypress - 347 M /kohadevbox/node_modules - 95 M /kohadevbox/misc4dev - 224 M /usr/lib/locale (does locales are needed for Koha? because all are generated) - 410 M /usr/lib/x86_64-linux-gnu , various lib, maybe libLLVM and guile are not needed - 93 M /usr/lib/gcc - 270 M /usr/share/locale & /usr/share/doc not sure that prunable depending on how packages are made in Debian. Maybe part can be pruned via a dirty rm -rf like it seems to be done for the apt repo metadata in dockerfiles. Seen that a few times. - 400 M /usr/local/share/.cache/yarn likely everything is needed to be able to rebuild CSS & vue without having to redownload. Which is done on start so not only needed when working with UI. Ok maybe some stuff is not needed? Same questions with /kohadevbox/node_modules npm(node) and yarn have redundancy in their cache >_< They share all of their top 10 packages (some with same size, other with quite different) ^^" I guess one is used for SCSS compilation and another one for vue and cypress. But they still have in common the packages of the 3, hmm Cheers, -- Victor Grousset/tuxayo ___ 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] Growing size of koha/koha-testing:master
Hi all, I've noticed recently that koha/koha-testing:master has been steadily growing. At this point, it's about 4.37GB in size. For 21.11 I think it used to be about 2GB and 22.11 was 3.5GB. Do we know what's contributing to this? 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] January point releases
Hi all, I think the January point releases have been done. Just curious when we'll see those flow through to the main repository? Thanks, David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 ___ 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] Dockerfile for koha/elasticsearch-icu:7.x image
Hi Tomas, Thanks for that. I had looked at that URL but I couldn’t find a Dockerfile there. Just LICENSE and README.md files. But I see now if I had selected a particular branch I would’ve been able to find the Dockerfile. Thanks again, 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 Sent: Monday, 29 January 2024 10:16 PM To: David Cook Cc: koha-devel Subject: Re: [Koha-devel] Dockerfile for koha/elasticsearch-icu:7.x image You can find the Dokerfiles here https://gitlab.com/koha-community/docker/koha-elasticsearch-icu and yes, they were just installing the ICU plugin El lun, 29 ene 2024 1:47, David Cook via Koha-devel mailto:koha-devel@lists.koha-community.org> > escribió: Hi all, Is there a published version of the Dockerfile for the koha/elasticsearch-icu:7.x image? Is it just running “RUN /usr/share/elasticsearch/bin/plugin install --batch analysis-icu” or does it make other changes to the standard image as well? 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 <mailto: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] Dockerfile for koha/elasticsearch-icu:7.x image
Hi all, Is there a published version of the Dockerfile for the koha/elasticsearch-icu:7.x image? Is it just running "RUN /usr/share/elasticsearch/bin/plugin install --batch analysis-icu" or does it make other changes to the standard image as well? 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] 22.11.12 having package dependency problems?
I help out a few libraries running 22.11 straight from the community, and two libraries lately have had Koha go down during automatic upgrades to 22.11.12-1. koha-common mostly installs but fails to complete due to unmet dependencies: apt install koha-common -s Reading package lists... Done Building dependency tree... Done Reading state information... Done koha-common is already the newest version (22.11.12-1). You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: koha-common : Depends: koha-l10n but it is not going to be installed E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). You can remedy this by running apt-get install koha-l10n, but I'm curious why this is happening. I imagine it must be happening to more libraries around the world as well. Maybe when the koha-common upgrade ran the koha-l10n package wasn't available? Has anyone else bumped into this? I didn't realize that we were backporting koha-l10n to other releases than 23.11, so it hasn't been on my radar until now. 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] "Online access" vs "Online resources"
Hi all, Detail pages say "Online resources" but search results say "Online access". I don't know if I've never noticed before or what but I had a librarian raise it today. I think it makes sense to harmonise so that they're both the same, but how do we choose which one? I've raised a ticket for this: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35410 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/
Re: [Koha-devel] Using Elasticsearch in koha-testing-docker
Thanks, Jonathan. I’ve done some playing around and I think I’m learning a lot about Koha’s integration. I’m a bit surprised that there isn’t an “any”, “all”, or “anywhere” index. I notice “ElasticsearchMARCFormat” can make the full MARC record searchable by storing the MARC record as a JSON object, but it seems like that’s not recommended. I don’t know why we wouldn’t just index the full record like we do with Zebra. It would make for a bigger data store, but it could be done fairly simply. Who all is actively contributing to the Elasticsearch work? Might be useful to get in on the conversation… 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: Jonathan Druart Sent: Tuesday, 7 November 2023 8:09 PM To: David Cook Cc: koha-devel Subject: Re: [Koha-devel] Using Elasticsearch in koha-testing-docker About ktd you need to include one of the ES/OS compose files (docker-compose.es <http://docker-compose.es> * docker-compose.os*), there are bin/ktd switches. You also need KOHA_ELASTICSEARCH set to "yes" in the .env file. Le mar. 7 nov. 2023 à 03:55, David Cook via Koha-devel mailto:koha-devel@lists.koha-community.org> > a écrit : Hi all, I’m trying to use Elasticsearch in koha-testing-docker, and I would appreciate some assistance. Here’s the steps I’m taking: 1. Launch koha-testing-docker 2. Update Koha’s sysprefs a. Change SearchEngine from “Zebra” to “Elasticsearch” at http://localhost:8081/cgi-bin/koha/admin/preferences.pl?op=search <http://localhost:8081/cgi-bin/koha/admin/preferences.pl?op=search=SearchEngine> =SearchEngine 3. (Re)build Elasticsearch indexes: a. koha-elasticsearch --rebuild kohadev 4. Start Elasticsearch indexer: a. koha-es-indexer --start kohadev Is there anything else to do? In a prod install, do I just need to update the “elasticsearch” config in koha-conf.xml? Do I leave all the Zebra things running or can I turn those off? I recall reading somewhere that zebra_queue might fill up if I turn it off? Thanks all! 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 <mailto: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] Using Elasticsearch in koha-testing-docker
Hi all, I'm trying to use Elasticsearch in koha-testing-docker, and I would appreciate some assistance. Here's the steps I'm taking: 1. Launch koha-testing-docker 2. Update Koha's sysprefs a. Change SearchEngine from "Zebra" to "Elasticsearch" at http://localhost:8081/cgi-bin/koha/admin/preferences.pl?op=search <http://localhost:8081/cgi-bin/koha/admin/preferences.pl?op=search ld=SearchEngine> =SearchEngine 3. (Re)build Elasticsearch indexes: a. koha-elasticsearch --rebuild kohadev 4. Start Elasticsearch indexer: a. koha-es-indexer --start kohadev Is there anything else to do? In a prod install, do I just need to update the "elasticsearch" config in koha-conf.xml? Do I leave all the Zebra things running or can I turn those off? I recall reading somewhere that zebra_queue might fill up if I turn it off? Thanks all! 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/
Re: [Koha-devel] Last month before the release
Also, regarding https://jenkins.koha-community.org/job/Koha_Master/lastCompletedBuild/testReport/ : I’ve got a fix for “t_db_dependent_Koha_Patrons_Import_t.No warning raised by import_patrons” at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35264 It looks like Katrin fixed “xt_author_valid_templates_t./kohadevbox/koha/koha-tmpl/intranet-tmpl/prog/en/modules/circ/circulation_batch_checkouts.tt” And I can’t reproduce the problem on master for “t_db_dependent_selenium_patrons_search_t.Search patrons”, so I’m guessing someone has already fixed that one? Hopefully the next run will be fail free :D 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: David Cook Sent: Monday, 6 November 2023 10:32 AM To: 'Jonathan Druart' Cc: 'Tomas Cohen Arazi' ; 'koha-devel' Subject: RE: [Koha-devel] Last month before the release Thanks, Jonathan. Yeah, I think having a live chat sounds like a plan. Communication is good. Timezones, especially mine, make it tough, but being able to point at documentation for policies and procedures is helpful. 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: Jonathan Druart mailto:jonathan.dru...@bugs.koha-community.org> > Sent: Friday, 3 November 2023 7:10 PM To: David Cook mailto:dc...@prosentient.com.au> > Cc: Tomas Cohen Arazi mailto:tomasco...@gmail.com> >; koha-devel mailto:koha-devel@lists.koha-community.org> > Subject: Re: [Koha-devel] Last month before the release David, if you don't know Jenkins and you are part of the QA team, I guess you are not alone to be lost with our CI structure and it means we have a big problem. Either motivation, or tools or communication. I am not answering you now but maybe we need to document a bit better how it works for the next release, responsibilize people (asking them to fix what they broke instead of fixing for them) and finally maybe have a live chat beginning of the cycle with RMaints and QA team to (re) explain how it works. Le vendredi 3 novembre 2023, David Cook via Koha-devel mailto:koha-devel@lists.koha-community.org> > a écrit : > It’s not clear to me though how you look at Jenkins runs. Is it going to > https://dashboard.koha-community.org/ and then clicking on one of the badges > to go to Jenkins like https://jenkins.koha-community.org/job/Koha_Master_U22/ > and then clicking on “Latest Test Result”? > > > > 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 mailto:tomasco...@gmail.com> > > Sent: Friday, 3 November 2023 11:25 AM > To: David Cook mailto:dc...@prosentient.com.au> > > Cc: koha-devel <mailto:koha-devel@lists.koha-community.org> > > Subject: Re: [Koha-devel] Last month before the release > > > > The suggested sequence is: > > > > 1. You notice your stuff for pushed, yay! > > 2. You look at Jenkins runs for the relevant branches (e.g. Koha_Master_* > tasks) > > 3. If some test gets broken that day, you try too see if it was you. Beware > sometimes it is not obvious. > > > > Today there was a failure in the holds API tests, because of a bug that > didn't touch the API, but made the code stricter (?) so the loose tests we > had written had to be tweaked so they didn't trigger a silly error. > > > > So the devs did right, didn't introduce a bug, but made the tests fail. But > it is all of us, specially those who got patches pushed, who should be > looking after those failures. Team work > > > > Thanks! > > > > El jue, 2 nov 2023 21:15, David Cook <mailto:dc...@prosentient.com.au> > escribió: > > What’s the best way to do this? > > > > I think Jenkins might send emails, but I think my mail server blocked it ages > ago as spam. > > > > David Cook > > Senior Software Engineer > > Prosentient Systems > > Suite 7.03 > > 6a Glen St > > Milsons Point NSW 2061 > > Australia > > > > Office: 02 9212 0899 > > Online: 02 8005 0595 > > > > From: Koha-devel <mailto:koha-devel-boun...@lists.koha-community.org> > On Behalf Of Tomas > Cohen Arazi via Koha-devel > Sent: Friday, 3 November 2023 12:31 AM > To: koha-devel <mailto:koha-devel@lists.koha-community.org> > > Subject: [Koha-devel] Last month before the release > > > &g
Re: [Koha-devel] Last month before the release
Thanks, Jonathan. Yeah, I think having a live chat sounds like a plan. Communication is good. Timezones, especially mine, make it tough, but being able to point at documentation for policies and procedures is helpful. 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: Jonathan Druart Sent: Friday, 3 November 2023 7:10 PM To: David Cook Cc: Tomas Cohen Arazi ; koha-devel Subject: Re: [Koha-devel] Last month before the release David, if you don't know Jenkins and you are part of the QA team, I guess you are not alone to be lost with our CI structure and it means we have a big problem. Either motivation, or tools or communication. I am not answering you now but maybe we need to document a bit better how it works for the next release, responsibilize people (asking them to fix what they broke instead of fixing for them) and finally maybe have a live chat beginning of the cycle with RMaints and QA team to (re) explain how it works. Le vendredi 3 novembre 2023, David Cook via Koha-devel mailto:koha-devel@lists.koha-community.org> > a écrit : > It’s not clear to me though how you look at Jenkins runs. Is it going to > https://dashboard.koha-community.org/ and then clicking on one of the badges > to go to Jenkins like https://jenkins.koha-community.org/job/Koha_Master_U22/ > and then clicking on “Latest Test Result”? > > > > 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 mailto:tomasco...@gmail.com> > > Sent: Friday, 3 November 2023 11:25 AM > To: David Cook mailto:dc...@prosentient.com.au> > > Cc: koha-devel <mailto:koha-devel@lists.koha-community.org> > > Subject: Re: [Koha-devel] Last month before the release > > > > The suggested sequence is: > > > > 1. You notice your stuff for pushed, yay! > > 2. You look at Jenkins runs for the relevant branches (e.g. Koha_Master_* > tasks) > > 3. If some test gets broken that day, you try too see if it was you. Beware > sometimes it is not obvious. > > > > Today there was a failure in the holds API tests, because of a bug that > didn't touch the API, but made the code stricter (?) so the loose tests we > had written had to be tweaked so they didn't trigger a silly error. > > > > So the devs did right, didn't introduce a bug, but made the tests fail. But > it is all of us, specially those who got patches pushed, who should be > looking after those failures. Team work > > > > Thanks! > > > > El jue, 2 nov 2023 21:15, David Cook <mailto:dc...@prosentient.com.au> > escribió: > > What’s the best way to do this? > > > > I think Jenkins might send emails, but I think my mail server blocked it ages > ago as spam. > > > > David Cook > > Senior Software Engineer > > Prosentient Systems > > Suite 7.03 > > 6a Glen St > > Milsons Point NSW 2061 > > Australia > > > > Office: 02 9212 0899 > > Online: 02 8005 0595 > > > > From: Koha-devel <mailto:koha-devel-boun...@lists.koha-community.org> > On Behalf Of Tomas > Cohen Arazi via Koha-devel > Sent: Friday, 3 November 2023 12:31 AM > To: koha-devel <mailto:koha-devel@lists.koha-community.org> > > Subject: [Koha-devel] Last month before the release > > > > Hi all. > > > > We are almost done with the release, a couple medium/big things to push > today/tomorrow and then bug fixing. > > > > I wanted to ask y'all to please view the Jenkins tasks status anytime after > your stuff has been pushed. I know I said this many times, but some devs > clearly break some tests that are trivially fixable and the team needs you to > take care of your breakages. > > > > I'm doing my best to track things and fix, but you should all be worried > about that. > > > > -- > > Tomás Cohen Arazi > > Theke Solutions (https://theke.io) > ✆ +54 9351 3513384 > GPG: B2F3C15F ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
Re: [Koha-devel] Last month before the release
It’s not clear to me though how you look at Jenkins runs. Is it going to https://dashboard.koha-community.org/ and then clicking on one of the badges to go to Jenkins like https://jenkins.koha-community.org/job/Koha_Master_U22/ and then clicking on “Latest Test Result”? 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 Sent: Friday, 3 November 2023 11:25 AM To: David Cook Cc: koha-devel Subject: Re: [Koha-devel] Last month before the release The suggested sequence is: 1. You notice your stuff for pushed, yay! 2. You look at Jenkins runs for the relevant branches (e.g. Koha_Master_* tasks) 3. If some test gets broken that day, you try too see if it was you. Beware sometimes it is not obvious. Today there was a failure in the holds API tests, because of a bug that didn't touch the API, but made the code stricter (?) so the loose tests we had written had to be tweaked so they didn't trigger a silly error. So the devs did right, didn't introduce a bug, but made the tests fail. But it is all of us, specially those who got patches pushed, who should be looking after those failures. Team work Thanks! El jue, 2 nov 2023 21:15, David Cook mailto:dc...@prosentient.com.au> > escribió: What’s the best way to do this? I think Jenkins might send emails, but I think my mail server blocked it ages ago as spam. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel mailto:koha-devel-boun...@lists.koha-community.org> > On Behalf Of Tomas Cohen Arazi via Koha-devel Sent: Friday, 3 November 2023 12:31 AM To: koha-devel mailto:koha-devel@lists.koha-community.org> > Subject: [Koha-devel] Last month before the release Hi all. We are almost done with the release, a couple medium/big things to push today/tomorrow and then bug fixing. I wanted to ask y'all to please view the Jenkins tasks status anytime after your stuff has been pushed. I know I said this many times, but some devs clearly break some tests that are trivially fixable and the team needs you to take care of your breakages. I'm doing my best to track things and fix, but you should all be worried about that. -- Tomás Cohen Arazi Theke Solutions (https://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
Re: [Koha-devel] Last month before the release
What’s the best way to do this? I think Jenkins might send emails, but I think my mail server blocked it ages ago as spam. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Tomas Cohen Arazi via Koha-devel Sent: Friday, 3 November 2023 12:31 AM To: koha-devel Subject: [Koha-devel] Last month before the release Hi all. We are almost done with the release, a couple medium/big things to push today/tomorrow and then bug fixing. I wanted to ask y'all to please view the Jenkins tasks status anytime after your stuff has been pushed. I know I said this many times, but some devs clearly break some tests that are trivially fixable and the team needs you to take care of your breakages. I'm doing my best to track things and fix, but you should all be worried about that. -- Tomás Cohen Arazi Theke Solutions (https://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
Re: [Koha-devel] Memory footprint of Koha processes
Hi Philippe, I run quite a few Koha instances, so I feel your pain. A couple months ago I opened https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34477 but I haven’t dedicated any time to work on it yet (and I have no plans to work on it anytime soon). The ORM eats up a lot of memory, and if I recall correctly C4::Context also requires a fair bit of memory. I don’t think you’ll really be able to hack this one per se as there are quite a few changes that are needed. That said… I suppose you could always create an alternative background jobs worker and use that instead. If I recall correctly, I don’t think you use the RabbitMQ, so you could exclude lots of code. In theory Koha::Database->dbh() should provide a database handle with a smaller memory footprint, but I haven’t tested it. But yeah… I think you’d basically need to do a rewrite. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Philippe Blouin via Koha-devel Sent: Tuesday, 24 October 2023 6:57 AM To: koha-devel@lists.koha-community.org Subject: [Koha-devel] Memory footprint of Koha processes Howdy! I'm trying to run a server with MANY koha instances (for educational purposes), but although the usage is very small, the resources required just make everything explode. background_jobs_worker.pl for instance uses 170M per instance, and plack uses 200M without anything being loaded. Any suggestion how this could be hacked (locally) to allow for 200 koha instances on a machine without requiring 100G of memory ? The object model seems at fault here, but I see no way to go around "use Koha::BackgroundJobs;" at the top of the script. Thanks! -- Philippe Blouin, Directeur de la technologie Tél. : (833) 465-4276, poste 230 <mailto:philippe.blo...@inlibro.com> philippe.blo...@inlibro.com inLibro | pour esprit libre | <http://www.inLibro.com> www.inLibro.com ___ 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] Anyone else having issues attaching patches to Bugzilla?
Turns out it was this problem: https://gitlab.com/koha-community/git-bz/-/issues/8#note_1180787597 I’d put the wrong bug number in the title line of the commit and that was causing the problem. Yikes. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of David Cook via Koha-devel Sent: Monday, 23 October 2023 1:47 PM To: 'David Nind' Cc: 'Koha Devel' Subject: Re: [Koha-devel] Anyone else having issues attaching patches to Bugzilla? Thanks for confirming, David! 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: David Nind mailto:da...@davidnind.com> > Sent: Monday, October 23, 2023 1:43 PM To: David Cook mailto:dc...@prosentient.com.au> > Cc: Koha Devel mailto:koha-devel@lists.koha-community.org> > Subject: Re: [Koha-devel] Anyone else having issues attaching patches to Bugzilla? Hi David. It's working for me, just signed of a patch - git bz attach -e X HEAD So it must be you! 8-) David Nind New Zealand On Mon, 23 Oct 2023 at 15:25, David Cook via Koha-devel mailto:koha-devel@lists.koha-community.org> > wrote: Hi all, Trying to attach a patch to Bugzilla this afternoon and I get the following error: Cleaning up back to original state on error Traceback (most recent call last): File "/usr/bin/git-bz", line 2840, in do_attach(*args) File "/usr/bin/git-bz", line 2168, in do_attach add_url(bug, commits) File "/usr/bin/git-bz", line 1719, in add_url add_url_to_head_commit(commit, bug) File "/usr/bin/git-bz", line 1682, in add_url_to_head_commit git.commit(file="-", amend=True, _input=input) File "/usr/bin/git-bz", line 197, in f o = git_run(command, *args, **kwargs) File "/usr/bin/git-bz", line 167, in git_run output, error = process.communicate(input) File "/usr/lib/python3.9/subprocess.py", line 1134, in communicate stdout, stderr = self._communicate(input, endtime, timeout) File "/usr/lib/python3.9/subprocess.py", line 1961, in _communicate input_view = memoryview(self._input) TypeError: memoryview: a bytes-like object is required, not 'str' I figure it’s probably a “me problem” but just want to check… 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 <mailto: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] I'm not getting your emails on bugs...
Hi all, It looks like my "bugmail has been disabled" for the last 10 days on Bugzilla, so if I haven't responded to a comment on Bugzilla, it's not because I'm ignoring you. It's because I'm not getting the emails. (If an administrator sees this, please re-enable my bugmail. Thanks!) I've been trying to weed through the contents from koha-b...@lists.koha-community.org <mailto:koha-b...@lists.koha-community.org> which I still receive but there's so many emails I'm likely to miss the vast majority. So if you need anything from me urgently, shoot me an email directly? 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/
Re: [Koha-devel] Anyone else having issues attaching patches to Bugzilla?
Thanks for confirming, David! 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: David Nind Sent: Monday, October 23, 2023 1:43 PM To: David Cook Cc: Koha Devel Subject: Re: [Koha-devel] Anyone else having issues attaching patches to Bugzilla? Hi David. It's working for me, just signed of a patch - git bz attach -e X HEAD So it must be you! 8-) David Nind New Zealand On Mon, 23 Oct 2023 at 15:25, David Cook via Koha-devel mailto:koha-devel@lists.koha-community.org> > wrote: Hi all, Trying to attach a patch to Bugzilla this afternoon and I get the following error: Cleaning up back to original state on error Traceback (most recent call last): File "/usr/bin/git-bz", line 2840, in do_attach(*args) File "/usr/bin/git-bz", line 2168, in do_attach add_url(bug, commits) File "/usr/bin/git-bz", line 1719, in add_url add_url_to_head_commit(commit, bug) File "/usr/bin/git-bz", line 1682, in add_url_to_head_commit git.commit(file="-", amend=True, _input=input) File "/usr/bin/git-bz", line 197, in f o = git_run(command, *args, **kwargs) File "/usr/bin/git-bz", line 167, in git_run output, error = process.communicate(input) File "/usr/lib/python3.9/subprocess.py", line 1134, in communicate stdout, stderr = self._communicate(input, endtime, timeout) File "/usr/lib/python3.9/subprocess.py", line 1961, in _communicate input_view = memoryview(self._input) TypeError: memoryview: a bytes-like object is required, not 'str' I figure it’s probably a “me problem” but just want to check… 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 <mailto: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] Keycloak as Identity Provider using Koha's users
Sounds good. Thanks, Paul! 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: Paul Derscheid Sent: Friday, October 20, 2023 8:07 PM To: David Cook ; 'Koha Devel' Cc: 'Renvoize, Martin' Subject: Re: Keycloak as Identity Provider using Koha's users Hi David, thanks for putting so much work into this. I will try to use it to for a third party integration a little down the road. I'll share my experience with you if you're interested (or write an issue if something is broken :D). Thanks again Paul On 10/19/23 03:01, David Cook wrote: Hi all, I’ve posted the Keycloak extension for using Koha’s user database as Keycloak’s user datastore: https://gitlab.com/minusdavid/keycloak-user-storage-koha This effectively allows you to use Koha (version 22.11.03 and upwards) as an Identity Provider – mediated via Keycloak (version 20 and up). So you can set up Koha to use Keycloak via SAML or OIDC and then have other third-party services like EBSCO EDS using the Keycloak, and thus you have SSO across the board while the users are fully managed through Koha, which is pretty cool. At some point, I might look into how I can host the built JAR on Gitlab as well, but I’ve provided the command to build the JAR using Docker, so it is very easy to do even if you’re not a Java expert. Let me know if you need any help trying it out. 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 -- LMSCloud GmbH Paul Derscheid - Software Engineer Bismarckstr. 3 - D-72764 Reutlingen m +49 174 2436308 e paul.dersch...@lmscloud.de <mailto:paul.dersch...@lmscloud.de> w www.lmscloud.de <http://www.lmscloud.de> ___ 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] Background jobs quirks
In the stacktrace, there is a reference to
/usr/share/perl5/DBIx/Class/Storage/BlockRunner.pm which seems to be
responsible for the reconnection.
Starman is based on /usr/share/perl5/Net/Server/PreFork.pm and I see that it
ignores SIGPIPE signals.
I’ve added a line to ignore SIGPIPE in background_jobs_worker.pl and that fixes
this problem. It will ignore the SIGPIPE and it will just reconnect.
A lot of the reports of people’s issues with Koha’s background jobs have been
vague, and I wonder if this 1 line fix will resolve a lot of their issues…
In any case, I’ve opened up this bug report:
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35111
I’ll get patches out for this ASAP.
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: Jonathan Druart
Sent: Thursday, October 19, 2023 5:41 PM
To: David Cook
Cc: Koha Devel ; Tomas Cohen Arazi
Subject: Re: [Koha-devel] Background jobs quirks
Hum weird, isn't DBIC supposed to deal with reconnection?
You could add the find in a try, then find again in the catch... (for debug
purpose!)
Or force a new DBMS connection for each job (C4::Context->dbh({new => 1})), but
that's not a long term solution.
Le jeu. 19 oct. 2023 à 08:04, David Cook mailto:dc...@prosentient.com.au> > a écrit :
Just one last one….
I put a Carp on to the SIGPIPE and sure enough it is the
Koha::BackgroundJobs->find() causing the SIGPIPE to be raised.
Of course, ignoring the SIGPIPE isn’t going to help because the job won’t be
fetched.
I’m not sure what the answer here is… and unfortunately I’ve ran out of time
today. With my work task, I’ll probably abandon using the background jobs for
the moment as I need to do something more reliable. I’ll think about this one
later…
at /kohadevbox/koha/misc/background_jobs_worker.pl
<http://background_jobs_worker.pl> line 62.
main::__ANON__("PIPE") called at /usr/share/perl5/DBIx/Class/Storage/DBI.pm
line 932
eval {...} called at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 932
DBIx::Class::Storage::DBI::connected(DBIx::Class::Storage::DBI::mysql=HASH(0x55b81d683d78))
called at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 850
DBIx::Class::Storage::DBI::__ANON__(DBIx::Class::Storage::BlockRunner=HASH(0x55b81f9d8d28))
called at /usr/share/perl5/DBIx/Class/Storage/BlockRunner.pm line 190
DBIx::Class::Storage::BlockRunner::__ANON__() called at
/usr/share/perl5/Context/Preserve.pm line 38
Context::Preserve::preserve_context(CODE(0x55b81fa01620), "replace",
CODE(0x55b81fa016c8)) called at
/usr/share/perl5/DBIx/Class/Storage/BlockRunner.pm line 213
DBIx::Class::Storage::BlockRunner::_run(DBIx::Class::Storage::BlockRunner=HASH(0x55b81f9d8d28),
CODE(0x55b81f9d8ce0)) called at
/usr/share/perl5/DBIx/Class/Storage/BlockRunner.pm line 105
DBIx::Class::Storage::BlockRunner::run(DBIx::Class::Storage::BlockRunner=HASH(0x55b81f9d8d28),
CODE(0x55b81f9d8ce0)) called at /usr/share/perl5/DBIx/Class/Storage/DBI.pm
line 856
DBIx::Class::Storage::DBI::dbh_do(undef, undef, "SELECT `me`.`id`,
`me`.`status`, `me`.`progress`, `me`.`size`"..., ARRAY(0x55b81f453d30),
ARRAY(0x55b81f81d380)) called at /usr/share/perl5/DBIx/Class/Storage/DBI.pm
line 1939
DBIx::Class::Storage::DBI::_execute(DBIx::Class::Storage::DBI::mysql=HASH(0x55b81d683d78),
"select", ARRAY(0x55b81f9d3278), ARRAY(0x55b81d7db5a8), HASH(0x55b81f16bd08),
HASH(0x55b81f6cc0b8)) called at /usr/share/perl5/DBIx/Class/Stor
age/DBI.pm line 2584
DBIx::Class::Storage::DBI::_select(DBIx::Class::Storage::DBI::mysql=HASH(0x55b81d683d78),
ARRAY(0x55b81f9d3278), ARRAY(0x55b81d7db5a8), HASH(0x55b81f16bd08),
HASH(0x55b81f4ce6c0)) called at /usr/share/perl5/DBIx/Class/Storage/DBI.pm
line 2761
DBIx::Class::Storage::DBI::select_single(DBIx::Class::Storage::DBI::mysql=HASH(0x55b81d683d78),
ARRAY(0x55b81f9d3278), ARRAY(0x55b81d7db5a8), HASH(0x55b81f16bd08),
HASH(0x55b81f4ce6c0)) called at /usr/share/perl5/DBIx/Class/ResultSet
.pm line 1101
DBIx::Class::ResultSet::single(DBIx::Class::ResultSet=HASH(0x55b81d89b180))
called at /usr/share/perl5/DBIx/Class/ResultSet.pm line 910
DBIx::Class::ResultSet::find(DBIx::Class::ResultSet=HASH(0x55b81f9d6b68),
12) called at /kohadevbox/koha/Koha/Objects.pm line 96
Koha::Objects::find("Koha::BackgroundJobs", 12) called at
/kohadevbox/koha/misc/background_jobs_worker.pl
<http://background_jobs_worker.pl> line 132
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: David Cook mailto:dc...@prosentient.com.au> >
Sent: Thursday, October 19, 2023 4:26 PM
To: 'Koha Devel' mailto:koha-devel
Re: [Koha-devel] Background jobs quirks
Just one last one..
I put a Carp on to the SIGPIPE and sure enough it is the
Koha::BackgroundJobs->find() causing the SIGPIPE to be raised.
Of course, ignoring the SIGPIPE isn't going to help because the job won't be
fetched.
I'm not sure what the answer here is. and unfortunately I've ran out of time
today. With my work task, I'll probably abandon using the background jobs
for the moment as I need to do something more reliable. I'll think about
this one later.
at /kohadevbox/koha/misc/background_jobs_worker.pl line 62.
main::__ANON__("PIPE") called at
/usr/share/perl5/DBIx/Class/Storage/DBI.pm line 932
eval {...} called at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 932
DBIx::Class::Storage::DBI::connected(DBIx::Class::Storage::DBI::mysql=HASH(0
x55b81d683d78)) called at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line
850
DBIx::Class::Storage::DBI::__ANON__(DBIx::Class::Storage::BlockRunner=HASH(0
x55b81f9d8d28)) called at /usr/share/perl5/DBIx/Class/Storage/BlockRunner.pm
line 190
DBIx::Class::Storage::BlockRunner::__ANON__() called at
/usr/share/perl5/Context/Preserve.pm line 38
Context::Preserve::preserve_context(CODE(0x55b81fa01620), "replace",
CODE(0x55b81fa016c8)) called at
/usr/share/perl5/DBIx/Class/Storage/BlockRunner.pm line 213
DBIx::Class::Storage::BlockRunner::_run(DBIx::Class::Storage::BlockRunner=HA
SH(0x55b81f9d8d28), CODE(0x55b81f9d8ce0)) called at
/usr/share/perl5/DBIx/Class/Storage/BlockRunner.pm line 105
DBIx::Class::Storage::BlockRunner::run(DBIx::Class::Storage::BlockRunner=HAS
H(0x55b81f9d8d28), CODE(0x55b81f9d8ce0)) called at
/usr/share/perl5/DBIx/Class/Storage/DBI.pm line 856
DBIx::Class::Storage::DBI::dbh_do(undef, undef, "SELECT `me`.`id`,
`me`.`status`, `me`.`progress`, `me`.`size`"..., ARRAY(0x55b81f453d30),
ARRAY(0x55b81f81d380)) called at /usr/share/perl5/DBIx/Class/Storage/DBI.pm
line 1939
DBIx::Class::Storage::DBI::_execute(DBIx::Class::Storage::DBI::mysql=HASH(0x
55b81d683d78), "select", ARRAY(0x55b81f9d3278), ARRAY(0x55b81d7db5a8),
HASH(0x55b81f16bd08), HASH(0x55b81f6cc0b8)) called at
/usr/share/perl5/DBIx/Class/Stor
age/DBI.pm line 2584
DBIx::Class::Storage::DBI::_select(DBIx::Class::Storage::DBI::mysql=HASH(0x5
5b81d683d78), ARRAY(0x55b81f9d3278), ARRAY(0x55b81d7db5a8),
HASH(0x55b81f16bd08), HASH(0x55b81f4ce6c0)) called at
/usr/share/perl5/DBIx/Class/Storage/DBI.pm
line 2761
DBIx::Class::Storage::DBI::select_single(DBIx::Class::Storage::DBI::mysql=HA
SH(0x55b81d683d78), ARRAY(0x55b81f9d3278), ARRAY(0x55b81d7db5a8),
HASH(0x55b81f16bd08), HASH(0x55b81f4ce6c0)) called at
/usr/share/perl5/DBIx/Class/ResultSet
.pm line 1101
DBIx::Class::ResultSet::single(DBIx::Class::ResultSet=HASH(0x55b81d89b180))
called at /usr/share/perl5/DBIx/Class/ResultSet.pm line 910
DBIx::Class::ResultSet::find(DBIx::Class::ResultSet=HASH(0x55b81f9d6b68),
12) called at /kohadevbox/koha/Koha/Objects.pm line 96
Koha::Objects::find("Koha::BackgroundJobs", 12) called at
/kohadevbox/koha/misc/background_jobs_worker.pl line 132
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: David Cook
Sent: Thursday, October 19, 2023 4:26 PM
To: 'Koha Devel'
Cc: 'Jonathan Druart' ; 'Tomas
Cohen Arazi'
Subject: RE: [Koha-devel] Background jobs quirks
Success!
I created the persistent database connection between the background job
worker and the database, and then I restarted the database.
When I tried to enqueue a background job, it's now stuck in a "New" status
with a Progress of "null/1", and /var/log/koha/kohadev/worker-error.log says
the following:
20231019 05:02:14 kohadev-koha-worker-long_tasks: client (pid 23247) killed
by signal 13, respawning
Now Starman seems to have managed to re-establish a connection without any
errors. It's not clear why that might be. I suppose Starman/Plack might be
suppressing SIGPIPE errors. We might have some subtle issues under the hood
without even realizing it.
(That suddenly reminds me of that MYSQL_OPT_RECONNECT issue from August.
MySQL 8.0.34/8.1.0 deprecate automatic reconnection. I would hope that
DBD::MySQL would take care of that, but as we might recall that module isn't
really maintained.)
I am testing on 22.11 so maybe it's a bit different in master. but it's
interesting.
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: David Cook mailto:dc...@prosentient.com.au>
>
Sent: Thursday, October 19, 2023 3:55 PM
To: 'David Cook' mailto:dc...@prosentient.com.au>
>; 'Koha Devel' mailto:koha-devel@lists.koha-community.org> >
Subject: RE: [Koha-devel] Background jobs quirks
On a standard Debian package install of Koha,
Re: [Koha-devel] Background jobs quirks
Success!
I created the persistent database connection between the background job
worker and the database, and then I restarted the database.
When I tried to enqueue a background job, it's now stuck in a "New" status
with a Progress of "null/1", and /var/log/koha/kohadev/worker-error.log says
the following:
20231019 05:02:14 kohadev-koha-worker-long_tasks: client (pid 23247) killed
by signal 13, respawning
Now Starman seems to have managed to re-establish a connection without any
errors. It's not clear why that might be. I suppose Starman/Plack might be
suppressing SIGPIPE errors. We might have some subtle issues under the hood
without even realizing it.
(That suddenly reminds me of that MYSQL_OPT_RECONNECT issue from August.
MySQL 8.0.34/8.1.0 deprecate automatic reconnection. I would hope that
DBD::MySQL would take care of that, but as we might recall that module isn't
really maintained.)
I am testing on 22.11 so maybe it's a bit different in master. but it's
interesting.
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: David Cook
Sent: Thursday, October 19, 2023 3:55 PM
To: 'David Cook' ; 'Koha Devel'
Subject: RE: [Koha-devel] Background jobs quirks
On a standard Debian package install of Koha, it looks like there are 3
persistent connections to the database: 2x Starman workers and 1x Zebra
Indexer.
Then if you use the background jobs, the background job worker for that
queue will create a persistent connection as well.
I had to work out the MySQL/MariaDB ID through trial and error since there
wasn't enough information in the processlist in the database, but I got the
ID, so I'll check the logs in the morning to see if that's the problem.
--
I'm losing some confidence in this theory as I'm looking at the
koha-testing-docker database instance and I'm seeing similar timeouts, but
it hasn't triggered the "killed by signal 13, respawning".
2023-10-19 3:06:09 44 [Warning] Aborted connection 44 to db: 'koha_kohadev'
user: 'koha_kohadev' host: '172.21.0.4' (Got an error reading communication
packets)
2023-10-19 3:06:09 32 [Warning] Aborted connection 32 to db: 'koha_kohadev'
user: 'koha_kohadev' host: '172.21.0.4' (Got an error reading communication
packets)
--
I'm thinking the best thing to do is just ignore SIGPIPE and let our regular
error handling take care of it, as we should then get a more nuanced error
message somewhere.
Looking at https://metacpan.org/dist/Net-Stomp/source/lib/Net/Stomp.pm and
it ignores SIGPIPE when it's sending frames. so it's probably not the
$conn->ack() doing it.
I do wonder if it's "my $job = Koha::BackgroundJobs->find($args->{job_id});"
I suppose we'll see in the morning.
David Cook
Senior Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
From: Koha-devel mailto:koha-devel-boun...@lists.koha-community.org> > On Behalf Of David
Cook via Koha-devel
Sent: Thursday, October 19, 2023 2:41 PM
To: 'Koha Devel' mailto:koha-devel@lists.koha-community.org> >
Subject: [Koha-devel] Background jobs quirks
Hi all,
Have you seen something like the following in your worker-error.log?
20231018 07:44:06 instance-koha-worker-long_tasks: client (pid 3949888)
killed by signal 13, respawning
20231019 07:21:26 instance-koha-worker-long_tasks: client (pid 4082852)
killed by signal 13, respawning
I found some discussion in a thread
https://www.mail-archive.com/koha@lists.katipo.co.nz/msg30046.html
Signal 13 would be a SIGPIPE I believe. At first, I assumed it was the
connection between the background worker and RabbitMQ, but based off the
RabbitMQ logs[1] that seemed unlikely.
MariaDB is another possibility. Looking at its logs [2] and I see some timed
out connections.
I might monitor the connections between the background workers and the
database tonight and see if it's related. It might also explain why it
happens on my MariaDB system but not my MySQL system.
Anyway, just putting out some feelers.
[1]
2023-10-18 07:44:06.492400+11:00 [info] <0.30487.131> accepting STOMP
connection <0.30487.131> (127.0.0.1:59120 -> 127.0.0.1:61613)
2023-10-18 07:44:06.500534+11:00 [info] <0.30487.131> closing STOMP
connection <0.30487.131> (127.0.0.1:59120 -> 127.0.0.1:61613)
2023-10-18 07:44:06.510426+11:00 [info] <0.20712.130> closing STOMP
connection <0.20712.130> (127.0.0.1:57508 -> 127.0.0.1:61613)
2023-10-18 07:44:08.703380+11:00 [info] <0.30518.131> accepting STOMP
connection <0.30518.131> (127.0.0.1:59882 -> 127.0.0.1:61613)
2023-10-19 07:21:26.254065+11:00 [info] <0.27344.133> accepting STOMP
connection <0.27344.133> (127.0.0
Re: [Koha-devel] Background jobs quirks
On a standard Debian package install of Koha, it looks like there are 3
persistent connections to the database: 2x Starman workers and 1x Zebra
Indexer.
Then if you use the background jobs, the background job worker for that
queue will create a persistent connection as well.
I had to work out the MySQL/MariaDB ID through trial and error since there
wasn't enough information in the processlist in the database, but I got the
ID, so I'll check the logs in the morning to see if that's the problem.
--
I'm losing some confidence in this theory as I'm looking at the
koha-testing-docker database instance and I'm seeing similar timeouts, but
it hasn't triggered the "killed by signal 13, respawning".
2023-10-19 3:06:09 44 [Warning] Aborted connection 44 to db: 'koha_kohadev'
user: 'koha_kohadev' host: '172.21.0.4' (Got an error reading communication
packets)
2023-10-19 3:06:09 32 [Warning] Aborted connection 32 to db: 'koha_kohadev'
user: 'koha_kohadev' host: '172.21.0.4' (Got an error reading communication
packets)
--
I'm thinking the best thing to do is just ignore SIGPIPE and let our regular
error handling take care of it, as we should then get a more nuanced error
message somewhere.
Looking at https://metacpan.org/dist/Net-Stomp/source/lib/Net/Stomp.pm and
it ignores SIGPIPE when it's sending frames. so it's probably not the
$conn->ack() doing it.
I do wonder if it's "my $job = Koha::BackgroundJobs->find($args->{job_id});"
I suppose we'll see in the morning.
David Cook
Senior Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
From: Koha-devel On Behalf Of
David Cook via Koha-devel
Sent: Thursday, October 19, 2023 2:41 PM
To: 'Koha Devel'
Subject: [Koha-devel] Background jobs quirks
Hi all,
Have you seen something like the following in your worker-error.log?
20231018 07:44:06 instance-koha-worker-long_tasks: client (pid 3949888)
killed by signal 13, respawning
20231019 07:21:26 instance-koha-worker-long_tasks: client (pid 4082852)
killed by signal 13, respawning
I found some discussion in a thread
https://www.mail-archive.com/koha@lists.katipo.co.nz/msg30046.html
Signal 13 would be a SIGPIPE I believe. At first, I assumed it was the
connection between the background worker and RabbitMQ, but based off the
RabbitMQ logs[1] that seemed unlikely.
MariaDB is another possibility. Looking at its logs [2] and I see some timed
out connections.
I might monitor the connections between the background workers and the
database tonight and see if it's related. It might also explain why it
happens on my MariaDB system but not my MySQL system.
Anyway, just putting out some feelers.
[1]
2023-10-18 07:44:06.492400+11:00 [info] <0.30487.131> accepting STOMP
connection <0.30487.131> (127.0.0.1:59120 -> 127.0.0.1:61613)
2023-10-18 07:44:06.500534+11:00 [info] <0.30487.131> closing STOMP
connection <0.30487.131> (127.0.0.1:59120 -> 127.0.0.1:61613)
2023-10-18 07:44:06.510426+11:00 [info] <0.20712.130> closing STOMP
connection <0.20712.130> (127.0.0.1:57508 -> 127.0.0.1:61613)
2023-10-18 07:44:08.703380+11:00 [info] <0.30518.131> accepting STOMP
connection <0.30518.131> (127.0.0.1:59882 -> 127.0.0.1:61613)
2023-10-19 07:21:26.254065+11:00 [info] <0.27344.133> accepting STOMP
connection <0.27344.133> (127.0.0.1:54116 -> 127.0.0.1:61613)
2023-10-19 07:21:26.259129+11:00 [info] <0.27344.133> closing STOMP
connection <0.27344.133> (127.0.0.1:54116 -> 127.0.0.1:61613)
2023-10-19 07:21:26.269652+11:00 [info] <0.30518.131> closing STOMP
connection <0.30518.131> (127.0.0.1:59882 -> 127.0.0.1:61613)
2023-10-19 07:21:26.660604+11:00 [info] <0.27372.133> accepting STOMP
connection <0.27372.133> (127.0.0.1:46178 -> 127.0.0.1:61613)
[2]
Oct 18 02:08:28 awesome-host mariadbd[959]: 2023-10-18 2:08:28 6308
[Warning] Aborted connection 6308 to db: 'koha_instance' user:
'koha_instance' host: 'localhost' (Got timeout reading communication
packets)
Oct 18 02:15:58 awesome-host mariadbd[959]: 2023-10-18 2:15:58 6304
[Warning] Aborted connection 6304 to db: 'koha_instance' user:
'koha_instance' host: 'localhost' (Got timeout reading communication
packets)
Oct 18 02:16:06 awesome-host mariadbd[959]: 2023-10-18 2:16:06 6303
[Warning] Aborted connection 6303 to db: 'koha_instance' user:
'koha_instance' host: 'localhost' (Got timeout reading communication
packets)
Oct 18 21:10:08 awesome-host mariadbd[959]: 2023-10-18 21:10:08 6380
[Warning] Aborted connection 6380 to db: 'koha_instance' user:
'koha_instance' host: 'localhost' (Got timeout reading communication
packets)
Oct 19 02:21:17 awesome-host mariadbd[959]: 2023-10-19 2:21:17 6431
[Warning] Aborted connection 6431 to db: 'koha_instance' user:
'koha_i
[Koha-devel] Background jobs quirks
Hi all, Have you seen something like the following in your worker-error.log? 20231018 07:44:06 instance-koha-worker-long_tasks: client (pid 3949888) killed by signal 13, respawning 20231019 07:21:26 instance-koha-worker-long_tasks: client (pid 4082852) killed by signal 13, respawning I found some discussion in a thread https://www.mail-archive.com/koha@lists.katipo.co.nz/msg30046.html Signal 13 would be a SIGPIPE I believe. At first, I assumed it was the connection between the background worker and RabbitMQ, but based off the RabbitMQ logs[1] that seemed unlikely. MariaDB is another possibility. Looking at its logs [2] and I see some timed out connections. I might monitor the connections between the background workers and the database tonight and see if it's related. It might also explain why it happens on my MariaDB system but not my MySQL system. Anyway, just putting out some feelers. [1] 2023-10-18 07:44:06.492400+11:00 [info] <0.30487.131> accepting STOMP connection <0.30487.131> (127.0.0.1:59120 -> 127.0.0.1:61613) 2023-10-18 07:44:06.500534+11:00 [info] <0.30487.131> closing STOMP connection <0.30487.131> (127.0.0.1:59120 -> 127.0.0.1:61613) 2023-10-18 07:44:06.510426+11:00 [info] <0.20712.130> closing STOMP connection <0.20712.130> (127.0.0.1:57508 -> 127.0.0.1:61613) 2023-10-18 07:44:08.703380+11:00 [info] <0.30518.131> accepting STOMP connection <0.30518.131> (127.0.0.1:59882 -> 127.0.0.1:61613) 2023-10-19 07:21:26.254065+11:00 [info] <0.27344.133> accepting STOMP connection <0.27344.133> (127.0.0.1:54116 -> 127.0.0.1:61613) 2023-10-19 07:21:26.259129+11:00 [info] <0.27344.133> closing STOMP connection <0.27344.133> (127.0.0.1:54116 -> 127.0.0.1:61613) 2023-10-19 07:21:26.269652+11:00 [info] <0.30518.131> closing STOMP connection <0.30518.131> (127.0.0.1:59882 -> 127.0.0.1:61613) 2023-10-19 07:21:26.660604+11:00 [info] <0.27372.133> accepting STOMP connection <0.27372.133> (127.0.0.1:46178 -> 127.0.0.1:61613) [2] Oct 18 02:08:28 awesome-host mariadbd[959]: 2023-10-18 2:08:28 6308 [Warning] Aborted connection 6308 to db: 'koha_instance' user: 'koha_instance' host: 'localhost' (Got timeout reading communication packets) Oct 18 02:15:58 awesome-host mariadbd[959]: 2023-10-18 2:15:58 6304 [Warning] Aborted connection 6304 to db: 'koha_instance' user: 'koha_instance' host: 'localhost' (Got timeout reading communication packets) Oct 18 02:16:06 awesome-host mariadbd[959]: 2023-10-18 2:16:06 6303 [Warning] Aborted connection 6303 to db: 'koha_instance' user: 'koha_instance' host: 'localhost' (Got timeout reading communication packets) Oct 18 21:10:08 awesome-host mariadbd[959]: 2023-10-18 21:10:08 6380 [Warning] Aborted connection 6380 to db: 'koha_instance' user: 'koha_instance' host: 'localhost' (Got timeout reading communication packets) Oct 19 02:21:17 awesome-host mariadbd[959]: 2023-10-19 2:21:17 6431 [Warning] Aborted connection 6431 to db: 'koha_instance' user: 'koha_instance' host: 'localhost' (Got timeout reading communication packets) Oct 19 02:24:02 awesome-host mariadbd[959]: 2023-10-19 2:24:02 6432 [Warning] Aborted connection 6432 to db: 'koha_instance' user: 'koha_instance' host: 'localhost' (Got timeout reading communication packets) 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] MIssing emails for CC list?
Hi all, I'm used to getting emails for issues I'm CCed to, but I don't think I've gotten any for the last 1 week. Is this happening to anyone else or is it just me? I'm still getting emails addressed to koha-b...@lists.koha-community.org <mailto:koha-b...@lists.koha-community.org> but not to me specifically. I'll check the mail server next I guess but figured I'd ask the question. 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] Keycloak as Identity Provider using Koha's users
Hi all, I've posted the Keycloak extension for using Koha's user database as Keycloak's user datastore: https://gitlab.com/minusdavid/keycloak-user-storage-koha This effectively allows you to use Koha (version 22.11.03 and upwards) as an Identity Provider - mediated via Keycloak (version 20 and up). So you can set up Koha to use Keycloak via SAML or OIDC and then have other third-party services like EBSCO EDS using the Keycloak, and thus you have SSO across the board while the users are fully managed through Koha, which is pretty cool. At some point, I might look into how I can host the built JAR on Gitlab as well, but I've provided the command to build the JAR using Docker, so it is very easy to do even if you're not a Java expert. Let me know if you need any help trying it out. 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] Koha Roadmap Link?
Hi all, The other day folk were talking about the difficulty of keeping track of roadmap bugs, and it reminded me that I often don't know where to find the roadmap. Googling it will often wind up with really old roadmaps or conversations about roadmaps. I'm thinking we could pop a link to the roadmap up on https://dashboard.koha-community.org/ ? I don't know about everyone else, but that's the place I go most often when I want information about Koha. 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/
Re: [Koha-devel] Background jobs in plugins
I thought about that although it’s worth restarting in any case, so the cache issue is probably not all that important. 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 Sent: Monday, October 16, 2023 4:13 PM To: David Cook Cc: Kyle Hall ; Koha Devel ; Kyle Hall Subject: Re: [Koha-devel] Background jobs in plugins Please file bug reports on your findings or ideas so they don't fall into void. El lun, 16 oct 2023 1:42, David Cook mailto:dc...@prosentient.com.au> > escribió: Thanks for doing that, Tomas. That was really helpful. Even with your email and the Github example, it still wasn’t working for me…until I realized that I should restart the background job workers. In hindsight, it’s obvious that the Koha/BackgroundJob.pm would only load the plugin 1 time. It also appears that the product of “plugin_types_to_classes” is also cached too long. My background workers would’ve cached the bad code and bad mapping early in my testing. The mapping cache doesn’t have an invalidation mechanism, so if you already have 1 plugin with a background task, I don’t think it’ll allow a 2nd plugin to appear in the mapping if a task from the 1st plugin is processed before the 2nd plugin is loaded. I haven’t thoroughly investigated that though… Overall, probably best to require a restart of the background workers as well as Plack any time a plugin is added which contains a background job. 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: Kyle Hall mailto:kyle.m.h...@gmail.com> > Sent: Saturday, October 14, 2023 2:48 AM To: Tomas Cohen Arazi mailto:tomasco...@gmail.com> > Cc: David Cook mailto:dc...@prosentient.com.au> >; Koha Devel mailto:koha-devel@lists.koha-community.org> >; Kyle Hall mailto:k...@bywatersolutions.com> > Subject: Re: [Koha-devel] Background jobs in plugins I love it Tomas! --- http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Fri, Oct 13, 2023 at 9:51 AM Tomas Cohen Arazi mailto:tomasco...@gmail.com> > wrote: Look at this commit: https://github.com/bywatersolutions/dev-koha-plugin-kitchen-sink/commit/30d1446387fa864fe49f25cb53a2915b33ef73ce Best regards El vie, 13 oct 2023 a las 10:09, Tomas Cohen Arazi (mailto:tomasco...@gmail.com> >) escribió: Hi all. I'm wrapping a KitchenSink patch to highlight how it would be used. The background jobs themselves work, but the template side I never looked at. I thought there was some default display showing all the report metadata, but it seems all descriptions are hardcoded and a dev is required to add the ability for plugins to advertise job descriptions and have them displayed as well. If you want a plugin background job, it works and you should look at the wiki (updated just now) and/or copy what I've done on the KitchenSink plugin. Regarding comments on IRC, the feature was submitted during the 2022's hackfest in an attempt to streamline the whole background jobs work by Jonathan, and was tested, QA and pushed by others. We succeeded in moving that forward, which Fridolin pushed for 22.05 and was a great improvement. Best regards El vie, 13 oct 2023 a las 3:25, David Cook (mailto:dc...@prosentient.com.au> >) escribió: Hi all, “Bug 30410 - Add a way for plugins to register background tasks” was pushed in Koha 22.05.00, but I can’t figure out how to make it work. Tomas, do you have a plugin where this works? I’ve gone through the patches, and it looks like I should have it right, but nothing I’m doing is working. When I enqueue the job, background_jobs.pl <http://background_jobs.pl> says “Unknown job type 'plugin_blah_blah'” even though “plugin_blah_blah” exists in Koha::BackgroundJob->new->type_class_mapping and in my plugin background job’s “job_type”. When I click “View” on the job, I get the following error: “Template process failed: file error - background_jobs/plugin_blah_blah.inc: not found at /kohadevbox/koha/C4/Templates.pm line 127” I’ll look next week at providing a simple plugin to illustrate the problem… Thanks, David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -- Tomás Cohen Arazi Theke Solutions (https://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F -- Tomás Cohen Arazi Theke Solutions (https://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F _
Re: [Koha-devel] Background jobs in plugins
Thanks for doing that, Tomas. That was really helpful. Even with your email and the Github example, it still wasn’t working for me…until I realized that I should restart the background job workers. In hindsight, it’s obvious that the Koha/BackgroundJob.pm would only load the plugin 1 time. It also appears that the product of “plugin_types_to_classes” is also cached too long. My background workers would’ve cached the bad code and bad mapping early in my testing. The mapping cache doesn’t have an invalidation mechanism, so if you already have 1 plugin with a background task, I don’t think it’ll allow a 2nd plugin to appear in the mapping if a task from the 1st plugin is processed before the 2nd plugin is loaded. I haven’t thoroughly investigated that though… Overall, probably best to require a restart of the background workers as well as Plack any time a plugin is added which contains a background job. 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: Kyle Hall Sent: Saturday, October 14, 2023 2:48 AM To: Tomas Cohen Arazi Cc: David Cook ; Koha Devel ; Kyle Hall Subject: Re: [Koha-devel] Background jobs in plugins I love it Tomas! --- http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Fri, Oct 13, 2023 at 9:51 AM Tomas Cohen Arazi mailto:tomasco...@gmail.com> > wrote: Look at this commit: https://github.com/bywatersolutions/dev-koha-plugin-kitchen-sink/commit/30d1446387fa864fe49f25cb53a2915b33ef73ce Best regards El vie, 13 oct 2023 a las 10:09, Tomas Cohen Arazi (mailto:tomasco...@gmail.com> >) escribió: Hi all. I'm wrapping a KitchenSink patch to highlight how it would be used. The background jobs themselves work, but the template side I never looked at. I thought there was some default display showing all the report metadata, but it seems all descriptions are hardcoded and a dev is required to add the ability for plugins to advertise job descriptions and have them displayed as well. If you want a plugin background job, it works and you should look at the wiki (updated just now) and/or copy what I've done on the KitchenSink plugin. Regarding comments on IRC, the feature was submitted during the 2022's hackfest in an attempt to streamline the whole background jobs work by Jonathan, and was tested, QA and pushed by others. We succeeded in moving that forward, which Fridolin pushed for 22.05 and was a great improvement. Best regards El vie, 13 oct 2023 a las 3:25, David Cook (mailto:dc...@prosentient.com.au> >) escribió: Hi all, “Bug 30410 - Add a way for plugins to register background tasks” was pushed in Koha 22.05.00, but I can’t figure out how to make it work. Tomas, do you have a plugin where this works? I’ve gone through the patches, and it looks like I should have it right, but nothing I’m doing is working. When I enqueue the job, background_jobs.pl <http://background_jobs.pl> says “Unknown job type 'plugin_blah_blah'” even though “plugin_blah_blah” exists in Koha::BackgroundJob->new->type_class_mapping and in my plugin background job’s “job_type”. When I click “View” on the job, I get the following error: “Template process failed: file error - background_jobs/plugin_blah_blah.inc: not found at /kohadevbox/koha/C4/Templates.pm line 127” I’ll look next week at providing a simple plugin to illustrate the problem… Thanks, David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -- Tomás Cohen Arazi Theke Solutions (https://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F -- Tomás Cohen Arazi Theke Solutions (https://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F ___ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : 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] Background jobs in plugins
Hi all, "Bug 30410 - Add a way for plugins to register background tasks" was pushed in Koha 22.05.00, but I can't figure out how to make it work. Tomas, do you have a plugin where this works? I've gone through the patches, and it looks like I should have it right, but nothing I'm doing is working. When I enqueue the job, background_jobs.pl says "Unknown job type 'plugin_blah_blah'" even though "plugin_blah_blah" exists in Koha::BackgroundJob->new->type_class_mapping and in my plugin background job's "job_type". When I click "View" on the job, I get the following error: "Template process failed: file error - background_jobs/plugin_blah_blah.inc: not found at /kohadevbox/koha/C4/Templates.pm line 127" I'll look next week at providing a simple plugin to illustrate the problem. Thanks, David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 ___ 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] Koha::Z3950Responder doesn't support authentication?
Hi all, Does anyone know if Koha::Z3950Responder supports authentication? As far as I know, it doesn't, so I've raised "Bug 35038 - Koha::Z3950Responder has no authentication" to flag that. Overall, I don't think I see the point of using z3950responder.pl in front of Zebra, but happy to be corrected. 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/
Re: [Koha-devel] Seeking comments on Bug 34745: ThingISBN broken
In the past, I had this problem with my OIDC implementation. CloudFlare didn't
like "libwww-perl/#.###', but it would accept an empty string. So I added
$ua->agent(""); and it worked fine after that.
I feel like I've had to do this somewhere else more recently as well but I
can't remember where... but I just updated my user agent string and it was all
good.
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 On Behalf Of
Owen Leonard
Sent: Friday, 29 September 2023 9:11 PM
To: Koha Devel
Subject: [Koha-devel] Seeking comments on Bug 34745: ThingISBN broken
I noticed recently that requests to LibraryThing's ThingISBN service are being
blocked. Koha tries to access a url like this:
https://www.librarything.com/api/thingISBN/0439139600
...which opens fine in a browser, but triggers the response "WARNING:
URL Request Failed 403 Forbidden" when Koha tries it.
Koha is currently sending the user agent "libwww-perl/6.52" and if I use
Firefox's developer tools to load the page with that set as a custom user agent
I get a CloudFlare-generated "access denied"
message.
I see other CloudFlare customers complaining about this, so it may just be a
default. Should we ask LibraryThing to change their configuration? Should we
send a less obtrusive user agent with the request?
-- Owen
--
Web Developer
Athens County Public Libraries
(740) 737-6006
https://www.myacpl.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/ git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/
[Koha-devel] Keycloak extension for using Koha as user storage backend
Hi all, Last year, I wrote a Keycloak extension for older Keycloak versions that uses Koha as a user storage backend. It allowed me to set up Keycloak as a shared IdP for Koha and other services, which allowed users to use their Koha credentials to log in. I'm almost finished writing an updated extension that works with the latest Keycloak 22+ (presumably Keycloak 20+ but I tested on Keycloak 22). I had to build a simple custom Docker image for Keycloak to include the extension, but I was able to get it to work in koha-testing-docker. If folk are interested in this work, I would be happy to look at sharing it. I have an increasing number of libraries who want an Identity Provider to provide SSO across Koha and other library services (like EBSCO's EDS), but they don't have an existing organisational Identity Provider. Keycloak fits well, and this extension makes it so easy for libraries and their users, since all the user management stays in Koha. 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] Timeout trying to edit SQL Reports Library
Hey folks, Has anyone tried editing the SQL Reports Library wiki for a while? I'm getting the following error when I try now: Error contacting the Parsoid/RESTBase server: (curl error: 28) Timeout was reached It's too bad because I just wrapped up a nice little report.. 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/
Re: [Koha-devel] plugins on KohaDevboxes
I’d hit F12 and look at the console. I imagine you’ll see some errors there. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Philippe Blouin Sent: Friday, 1 September 2023 6:15 AM To: koha-devel@lists.koha-community.org Subject: [Koha-devel] plugins on KohaDevboxes Hi! Any suggestion onto why our plugin doesn't seem to work on (bywater's) Devboxes while being perfectly fine in 22,23 or master local installs ? The UI of the config is all damaged, like the dropbox not being clickable. Below first is the devbox version, versus our installations right after. Any hint would be greatly appreciated. Thanks -- Philippe Blouin, Directeur de la technologie Tél. : (833) 465-4276, poste 230 <mailto:philippe.blo...@inlibro.com> philippe.blo...@inlibro.com inLibro | pour esprit libre | <http://www.inLibro.com> www.inLibro.com ___ 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] Admin access to Bugzilla
Thanks, Katrin. Chris unblocked me 20 minutes ago or so, but thanks for taking a look! 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: Katrin Fischer Sent: Friday, 25 August 2023 10:49 AM To: David Cook ; Koha Devel Subject: Re: [Koha-devel] Admin access to Bugzilla Hi David, I had a look at your account, but couldn't see anything wrong with it. Is it still not working? What is the message you are seeing? Katrin On 25.08.23 01:46, David Cook wrote: Hi all, Does anyone but Chris Cormack have admin access to Bugzilla? I’ve been locked out (due to posting too many links), and it would be great to get access back. I was hoping to do some work on Bugzilla today. 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 <mailto: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] Admin access to Bugzilla
Hi all, Does anyone but Chris Cormack have admin access to Bugzilla? I've been locked out (due to posting too many links), and it would be great to get access back. I was hoping to do some work on Bugzilla today. 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/
Re: [Koha-devel] How did we implement Verovio?
I was thinking the same thing about the lack of activity. It's interesting since "verovio" was updated just a few days ago. Looks like Agustin got some commits into midi-player back in 2019... I'm down with patching our copy though. The browser API issue is a worry. At some point we might just need a different MIDI player... 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 On Behalf Of Owen Leonard Sent: Friday, 25 August 2023 1:31 AM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] How did we implement Verovio? > I’ll raise an issue with them. The git repo hasn’t been updated in over 2 > years but fingers crossed. I'm not optimistic based on the lack of activity in other issues raised there. At the very least we can patch our copy of the library with a simple fix to remove the onclicks. The bigger issue may turn out to be that the library is using outdated browser APIs: https://github.com/rism-digital/midi-player/issues/30. -- Owen -- Web Developer Athens County Public Libraries (740) 737-6006 https://www.myacpl.org ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/ ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
[Koha-devel] How did we implement Verovio?
Hi all, I've gotten auto-blocked on Bugzilla, so I figured I'd go to the listserv while I wait for my access to be restored. I was reading https://book.verovio.org/installing-or-building-from-sources/javascript-and- webassembly.html and it makes me think "koha-tmpl/opac-tmpl/lib/verovio/verovio-toolkit.js" comes from https://github.com/rism-digital/verovio/releases However, it's not clear where "koha-tmpl/opac-tmpl/lib/verovio/midiplayer.js" comes from. After some digging, I found that it comes from here: https://github.com/rism-digital/midi-player/blob/master/player/midiplayer.js I reckon we should include some links on the about.pl to show where we got the code. Anyway, my issue with it was how it dynamically creates HTML with "onclick" event handlers, which aren't compatible with Content-Security-Policy. I'll raise an issue with them. The git repo hasn't been updated in over 2 years but fingers crossed. 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] DBD::mysql unmaintained
Hi all, Daniël van Eeden, the person who releases DBD::mysql on CPAN and has push privileges to https://github.com/perl5-dbi/DBD-mysql, has said that he is no longer maintaining DBD::mysql. That explains why Ubuntus package seems to just be stacking up patches on top of the last release from 2019. (Im glad I dont use DBD::mysql from CPAN. I do use DBD::Pg from CPAN but its much better maintained.) Anyway, Im asking for more information about the future of DBD::mysql, and thought Id keep you all informed. 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/
Re: [Koha-devel] WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version.
I knew that it was "supposed" to fix it. I just haven't personally confirmed that it "definitely" fixes it haha. But there have been lots of people on the Github issue that have said it has fixed it for them so it seems pretty safe. That said, pali (the 2nd biggest contributor to DBD::mysql) has said that the fix used by Ubuntu isn't enough and he has an alternative set of patches to use. Interesting seeing this all play out upstream... 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 On Behalf Of Fridolin SOMERS Sent: Tuesday, 22 August 2023 4:47 AM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version. You can see it in changelog : http://changelogs.ubuntu.com/changelogs/pool/universe/libd/libdbd-mysql-perl/libdbd-mysql-perl_4.050-3ubuntu0.2/changelog Le 17/08/2023 à 13:24, David Cook a écrit : > Letting folks know that Ubuntu have released a patched > libdbd-mysql-perl which claims to have fixed the issue. > > I haven’t confirmed that it fixes it myself, but it should be a > trivial change, so I imagine that it does. > > David Cook > > Senior Software Engineer > > Prosentient Systems > > Suite 7.03 > > 6a Glen St > > Milsons Point NSW 2061 > > Australia > > Office: 02 9212 0899 > > Online: 02 8005 0595 > > *From:*Koha-devel *On > Behalf Of *David Cook > *Sent:* Wednesday, 16 August 2023 2:36 PM > *To:* koha-devel@lists.koha-community.org > *Subject:* [Koha-devel] WARNING: MYSQL_OPT_RECONNECT is deprecated and > will be removed in a future version. > > Hi all, > > If you’re using Ubuntu, you may have noticed this message filling up > your logs. > > It looks like Ubuntu recently released a version of libmysqlclient21 > which outputs this warning message if you try to set MYSQL_OPT_RECONNECT. > > DBD::mysql sets it to false and therein lies the problem: > https://github.com/perl5-dbi/DBD-mysql/issues/354 > <https://github.com/perl5-dbi/DBD-mysql/issues/354> > > At a glance, the only real short-term option seems to be to downgrade > the MySQL client, but keeping my eyes open… > > 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/ -- Fridolin SOMERS Software and system maintainer 濾 BibLibre, France ___ 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] WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version.
Letting folks know that Ubuntu have released a patched libdbd-mysql-perl which claims to have fixed the issue. I haven't confirmed that it fixes it myself, but it should be a trivial change, so I imagine that it does. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of David Cook Sent: Wednesday, 16 August 2023 2:36 PM To: koha-devel@lists.koha-community.org Subject: [Koha-devel] WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version. Hi all, If you're using Ubuntu, you may have noticed this message filling up your logs. It looks like Ubuntu recently released a version of libmysqlclient21 which outputs this warning message if you try to set MYSQL_OPT_RECONNECT. DBD::mysql sets it to false and therein lies the problem: https://github.com/perl5-dbi/DBD-mysql/issues/354 At a glance, the only real short-term option seems to be to downgrade the MySQL client, but keeping my eyes open. 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] WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version.
Hi all, If you're using Ubuntu, you may have noticed this message filling up your logs. It looks like Ubuntu recently released a version of libmysqlclient21 which outputs this warning message if you try to set MYSQL_OPT_RECONNECT. DBD::mysql sets it to false and therein lies the problem: https://github.com/perl5-dbi/DBD-mysql/issues/354 At a glance, the only real short-term option seems to be to downgrade the MySQL client, but keeping my eyes open. 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/
Re: [Koha-devel] [Koha] Where would I put the OpenLibrary ID in the MARC record
Hi Nigel, That's looking good to me. When you're ready with a patch, you can use "git bz" in koha-testing-docker to upload the patch to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34527 and then testers and QA will take it from there. Joubu (Jonathan Druart) has a lot of work to do, so I'm sure he wouldn't mind you working on this! Being familiar with the original code, you might find he comments on the patch/report at some stage. 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: Nigel Titley Sent: Monday, 14 August 2023 9:40 PM To: David Cook ; koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] [Koha] Where would I put the OpenLibrary ID in the MARC record Hi David Many thanks. I've read the documentation, created a koha bugzilla account, created an enhancement request and assigned to myself, just to kick this off. However, looks like the original author of the OpenLibrary cover retrieval code (joubu) is still around so they may be better equipped than me to deal with this. I don't want to tread on anyone's toes. If this isn't the right process then please let me know. All the best and thanks to the wonderful koha community for being so helpful. Nigel On 14/08/2023 02:18, David Cook wrote: > Hi Nigel, > > "I'm going to do this in a docker container" is what I say for most of my > code projects (at home and the office). So long as you're not working with > SystemD, it generally makes everything easier. > > I think this wiki page might describe the process best: > https://wiki.koha-community.org/wiki/Development_workflow > > And for the practical aspect of submitting the patch, you'll want to > look at https://wiki.koha-community.org/wiki/Git_bz_configuration > > Let us know if you have any issues. > > Once your patch is accepted, you'll also join this list: > https://git.koha-community.org/stats/koha-master/authors.html > > 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: Nigel Titley > Sent: Friday, 11 August 2023 8:01 PM > To: David Cook ; > koha-devel@lists.koha-community.org > Subject: Re: [Koha-devel] [Koha] Where would I put the OpenLibrary ID > in the MARC record > > And that, as if by magic, answers what was to be my next question... the > koha-testing-docker instructions look comprehensive and I can try them out on > my desktop, which seems to meet the requirements. My son, when I was > discussing the project with him, said "you should do this in a docker > container" and as usual he was right. > > I presume that once/if I've got it working there's a submission process to > get updates back to the main Koha branch. > > All the best > > Nigel > > On 11/08/2023 00:07, David Cook wrote: >> That's great news, Nigel! I'm really happy that worked out. >> >> Have you looked at koha-testing-docker? >> https://gitlab.com/koha-community/koha-testing-docker >> >> You could do the development work on there and then wait/hope for it to flow >> down to your 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 >> >> -Original Message- >> From: Koha-devel On >> Behalf Of Nigel Titley >> Sent: Thursday, 10 August 2023 6:40 PM >> To: koha-devel@lists.koha-community.org >> Subject: Re: [Koha-devel] [Koha] Where would I put the OpenLibrary ID >> in the MARC record >> >> >> >> On 08/08/2023 10:58, Nigel Titley wrote: >>> >>> >>> On 24/07/2023 01:11, David Cook wrote: >>> >>>> You could send a request for an "openlibrary" code to be added to >>>> the official Standard Identifier Source Codes list: >>>> https://www.loc.gov/standards/sourcelist/index.html#maintenance . >>>> Honestly, I'm a little surprised there isn't already an entry for >>>> it there. I'm sure they'd approve a request for it. >>> >>> I've put in a request to the LOC. We'll see if anything comes of it. >>> They may request (I would do so in their place) that the request >>> comes from the Open Library itself in which case I'll have to chase >>> that route first. >> >> Well, to my surprise LOC got back to me today an
Re: [Koha-devel] [Koha] Where would I put the OpenLibrary ID in the MARC record
Hi Nigel, "I'm going to do this in a docker container" is what I say for most of my code projects (at home and the office). So long as you're not working with SystemD, it generally makes everything easier. I think this wiki page might describe the process best: https://wiki.koha-community.org/wiki/Development_workflow And for the practical aspect of submitting the patch, you'll want to look at https://wiki.koha-community.org/wiki/Git_bz_configuration Let us know if you have any issues. Once your patch is accepted, you'll also join this list: https://git.koha-community.org/stats/koha-master/authors.html 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: Nigel Titley Sent: Friday, 11 August 2023 8:01 PM To: David Cook ; koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] [Koha] Where would I put the OpenLibrary ID in the MARC record And that, as if by magic, answers what was to be my next question... the koha-testing-docker instructions look comprehensive and I can try them out on my desktop, which seems to meet the requirements. My son, when I was discussing the project with him, said "you should do this in a docker container" and as usual he was right. I presume that once/if I've got it working there's a submission process to get updates back to the main Koha branch. All the best Nigel On 11/08/2023 00:07, David Cook wrote: > That's great news, Nigel! I'm really happy that worked out. > > Have you looked at koha-testing-docker? > https://gitlab.com/koha-community/koha-testing-docker > > You could do the development work on there and then wait/hope for it to flow > down to your 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 > > -Original Message- > From: Koha-devel On > Behalf Of Nigel Titley > Sent: Thursday, 10 August 2023 6:40 PM > To: koha-devel@lists.koha-community.org > Subject: Re: [Koha-devel] [Koha] Where would I put the OpenLibrary ID > in the MARC record > > > > On 08/08/2023 10:58, Nigel Titley wrote: >> >> >> On 24/07/2023 01:11, David Cook wrote: >> >>> You could send a request for an "openlibrary" code to be added to >>> the official Standard Identifier Source Codes list: >>> https://www.loc.gov/standards/sourcelist/index.html#maintenance . >>> Honestly, I'm a little surprised there isn't already an entry for it >>> there. I'm sure they'd approve a request for it. >> >> I've put in a request to the LOC. We'll see if anything comes of it. >> They may request (I would do so in their place) that the request >> comes from the Open Library itself in which case I'll have to chase >> that route first. > > Well, to my surprise LOC got back to me today and said they had added Open > Library to the SISC list. > > https://loc.gov/marc/relators/tn230808src.html > > So we now have a standardised way to add OLIDs to a MARC record > > 024 7 _ | $2 openlib | $a > > And that means I can have a look at adding OLIDs to the cover art retrieval > from Open Library... which means dusting off my... erk... > javascript. Which means sorting out sympa so I can get Koha up to date... > > Nigel > ___ > Koha-devel mailing list > Koha-devel@lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ git : > https://git.koha-community.org/ bugs : https://bugs.koha-community.org/ > ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
Re: [Koha-devel] [Koha] Where would I put the OpenLibrary ID in the MARC record
That's great news, Nigel! I'm really happy that worked out. Have you looked at koha-testing-docker? https://gitlab.com/koha-community/koha-testing-docker You could do the development work on there and then wait/hope for it to flow down to your 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 -Original Message- From: Koha-devel On Behalf Of Nigel Titley Sent: Thursday, 10 August 2023 6:40 PM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] [Koha] Where would I put the OpenLibrary ID in the MARC record On 08/08/2023 10:58, Nigel Titley wrote: > > > On 24/07/2023 01:11, David Cook wrote: > >> You could send a request for an "openlibrary" code to be added to the >> official Standard Identifier Source Codes list: >> https://www.loc.gov/standards/sourcelist/index.html#maintenance . >> Honestly, I'm a little surprised there isn't already an entry for it >> there. I'm sure they'd approve a request for it. > > I've put in a request to the LOC. We'll see if anything comes of it. > They may request (I would do so in their place) that the request comes > from the Open Library itself in which case I'll have to chase that > route first. Well, to my surprise LOC got back to me today and said they had added Open Library to the SISC list. https://loc.gov/marc/relators/tn230808src.html So we now have a standardised way to add OLIDs to a MARC record 024 7 _ | $2 openlib | $a And that means I can have a look at adding OLIDs to the cover art retrieval from Open Library... which means dusting off my... erk... javascript. Which means sorting out sympa so I can get Koha up to date... Nigel ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/ ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
Re: [Koha-devel] koha-testing-docker missing koha-conf.xml
It’s not meant for production usage. That’s why https://gitlab.com/koha-community/koha-testing-docker says “Dockered development and testing environment for the Koha project”. Some people use containers for Koha in production but they use their own Docker images. I don’t think that there’s widespread interest in the Koha community creating Docker images for production. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Waylon Robertson Sent: Saturday, 22 July 2023 10:26 AM To: Jonathan Druart Cc: Koha Devel Subject: Re: [Koha-devel] koha-testing-docker missing koha-conf.xml yes, turns out, the ktd scripts don't create a proper koha config directory, so.. ktd can't be used for multiple libraries, and that the koha start script does setup every time it starts, means it can't be used for a docker image for production use. need to build koha-koha-1 myself i guess. Waylon On Friday, 21 July 2023 at 08:59:46 pm NZST, Jonathan Druart mailto:jonathan.dru...@bugs.koha-community.org> > wrote: How did you modify .env? Keep those as it: KOHA_INSTANCE=kohadev KOHA_CONF=/etc/koha/sites/kohadev/koha-conf.xml Le jeu. 20 juil. 2023 à 07:19, Waylon Robertson mailto:wrobertson1...@yahoo.co.nz> > a écrit : > > after doing ktd up, after configuring the database info etc in .env, I am > getting > koha-koha-1 | Running > [PERL5LIB=/kohadevbox/koha:/kohadevbox/koha/lib:/kohadevbox/qa-test-tools > perl /kohadevbox/misc4dev/setup_sip.pl --instance=emmaus]... > koha-koha-1 | unable to locate Koha configuration file koha-conf.xml at > /kohadevbox/koha/C4/Context.pm line 171. > > > etc. What am i missing? > > Hopefully someone picks this up, as it's needed to be done before next week > start. > > Waylon > > ___ > Koha-devel mailing list > Koha-devel@lists.koha-community.org > <mailto:Koha-devel@lists.koha-community.org> > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
Re: [Koha-devel] [Koha] Where would I put the OpenLibrary ID in the MARC record
Hi Nigel, While it's been a while since I worked in a library myself, I've got the librarian degree, I've been working in the library world for nearly 20 years, and I've been working on Koha for over 10 years. In cases like this, the answer is often "it depends". I would be tempted to put the OpenLibrary ID into the 024$a but as you've noted there isn't an easy standard way to indicate that it's an OpenLibrary ID, which is quite important for a case like this. That certainly makes things tricky. You could send a request for an "openlibrary" code to be added to the official Standard Identifier Source Codes list: https://www.loc.gov/standards/sourcelist/index.html#maintenance . Honestly, I'm a little surprised there isn't already an entry for it there. I'm sure they'd approve a request for it. Now here's where "it depends" comes in the most. Are you going to exchange your MARC records with other systems or just use them locally? If it's just locally, you could cheat and use a 024$2 of "openlibrary". Of course, you'd still need to write code to look for a 024$a with a 024$2 of "openlibrary". It would be fine if you kept that code local to your Koha, but the Koha community might not accept it upstream. Another option could be to use a 024$2 of "uri" and store the whole OpenLibrary URI like https://openlibrary.org/books/OL49198571M/Analogue_Men. The code could look for URIs with a hostname of "openlibrary.org" and then extract the ID from the URI. There's a growing usage of URIs for identifiers in the MARC world (long story why). You often see these as $0 subfields: https://www.loc.gov/marc/bibliographic/ecbdcntf.html. This would fit within the rules for MARC, but the downside is it would require you to write new code. It's also still arguably unconventional. As Jonathan pointed out, Koha only uses the ISBN to get OpenLibrary covers, although it looks like the OpenLibrary API has some options available for things like the OpenLibrary ID. Extending that API usage by Koha would probably involve Javascript, Template Toolkit changes, and maybe Perl changes. Keeping custom code local can be a bit of a headache in the long-run though, as then you can't rely on the regular releases from the Koha community without doing a fair bit of extra work. If you're running Koha 23.05+, you could look at writing a Koha plugin, which uses the new "opac_cover_images" hook[1]. This would involve some short-term work, but it would let you implement what you need. Going back to "it depends", in the library world we like to follow standards... until they don't work for us. Then we have local policies. Every library has their own way of doing things. (Another thing to notice with MARC is that when you encounter the number "9", it typically stands for a local field/subfield. Koha uses some of these fields/subfields for its own local purposes, and you can always do the same. The limit is just that "9" only makes sense for your library. You could always use a 024$9 of "openlibrary" along with a Koha plugin to achieve your goal. It wouldn't be following the library standards 100% but it's the kind of thing that does get done in the library world. Does that make sense? [1] https://wiki.koha-community.org/wiki/Koha_Plugin_Hooks https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32680 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 On Behalf Of Nigel Titley Sent: Friday, 21 July 2023 11:06 PM To: Jonathan Druart Cc: k...@lists.katipo.co.nz; koha-devel Subject: Re: [Koha-devel] [Koha] Where would I put the OpenLibrary ID in the MARC record Understood. I'm sure that a Real Librarian (tm) will answer at some point. Thanks anyway Nigel On 21/07/2023 13:20, Jonathan Druart wrote: > No idea, I'm really just a programmer ;) > > Le ven. 21 juil. 2023 à 14:06, Nigel Titley a écrit : >> >> Thanks for the response... makes sense to use the ISBN and it >> explains the observed behaviour. >> >> I've had a look at the code. One of these days I'll blow the dust off >> my JS manuals and see if I can do something to extend the code (JS >> isn't my favourite language and I've probably not written any for about 15 >> years). >> >> Is my supposition about where it would go in the MARC record correct? >> >> Thanks >> >> Nigel >> >> On 21/07/2023 12:29, Jonathan Druart wrote: >>> Looks like it's only using the ISBN. The code is in >>> koha-tmpl/opac-tmpl/bootstrap/js/openlibrary.js >>> >>> https://gitlab.com/koha-community/Koha/-/blob/master/koha-tmpl/opac- >>> tmpl
[Koha-devel] Run Koha plugin method from CLI
Hi all,
Do you ever want to run a Koha plugin method from the CLI? I know I sure do,
so I raised this issue and attached a patch:
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34335
I was able to upload a simple plugin and run the following: perl
misc/run_koha_plugin.pl --class
Koha::Plugin::Prosentient::CustomMethodPlugin --method awesome_method
--params '{"msg": "this is awesome"}'
This could be useful for manual tasks, cronjobs, or whatever really.
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] Net::Netmask gotcha for ILS-DI:AuthorizedIPs
Hi all, I've recently noticed that Net::Netmask 2.000+ no longer supports abbreviated IPv4 netblocks (e.g. 216.240). If your Koha libraries have used this in their configurations, they'll no longer work. They need to use one of the supported methods like CIDR format: 216.240.0.0/16. Just FYI! 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] Perl 5.38 released
Hi all, I don't know about you, but I don't follow Perl development super closely. But something Kyle said on Bugzilla about function decorators got me thinking about Ovid's work on Corinna, which led me to https://ovid.github.io/blog/politics-in-programming.html and then https://perldoc.perl.org/5.38.0/perldelta. It looks like 5.38 has an experimental "class" feature for defining Perl classes in a new (more common) way. Obviously we're not going to use experimental features, but it's interesting to see the direction Perl is heading. 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] Faster database update checks
Hi all, I just wanted to bring people's attention to my bug "Bug 34088 - Schema upgrade should short circuit faster if no upgrade needs to be done". It can check if Koha needs a database update in a fraction of the time of the current code. When you have a lot of Koha databases, processing database updates (especially when there is no update to do!) takes a long time. But you can check 60 databases in about 3.5 seconds with my patch (instead of over 60 seconds). This should speed up deployments. -- On a side note, I think that having #DEBHELPER# *before* koha-upgrade-schema means that Koha is started up *before* the database is upgraded. I'd have to double-check that, but it could lead to buggy behaviour. 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/
Re: [Koha-devel] Dockerized Koha
By the way, I’ve raised bug 34088 to fix the slowness of the database upgrade
checks. I’ve got a workable patch there, and I’ll look at polishing it up when
I have a bit more free time.
With the database upgrade check time fixed, I think we could do an
“check_for_updates.sh” script in the Docker container entry point script.
David Cook
Senior Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
From: Koha-devel On Behalf Of
David Cook
Sent: Thursday, June 22, 2023 10:09 AM
To: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] Dockerized Koha
Personally, I don’t need it at the moment, although I briefly thought I might
for one library.
Sometimes I wonder about design…
1. Would it be 1 Koha instance per container, or would it be a
multi-tenant Koha in 1 container?
2. *How would upgrades be handled?*
a. At the moment, when you install a new package, post-install hooks
upgrade the database and change some configuration files. But that wouldn’t
work if you install the package when making a new Docker image. Those hooks
wouldn’t be invoked on the production system when you launch a new container
from the new image.
i. The
solution there might be to make a new script for performing upgrades, and for
backwards compatibility it would still be called by the DEB post-install hooks,
and the Docker entrypoint.sh could call it at startup time.
1. Although if it were called at startup time, that could make startup
unnecessarily slow, since the database upgrade check is very slow even when it
has no work to do. (I have been meaning to fix that…)
2. How would configuration files be persisted?
a. If you have 1 Koha instance per container, you could just mount
individual files, but there are a lot of configuration files, so that might get
burdensome.
b. If you have multi-tenant Koha, maybe you could mount the entirety of
/etc/koha/sites. That would probably work well.
i. I don’t
think you could mount /etc/koha because a lot of those files are generated by
the koha-common package at install time, so you’d want to pick them up from the
Docker image.
4. How would other files be persisted?
a. Mount to /var/lib/koha, /var/spool/koha, /var/log/koha(?)
Anything else I’ve missed?
David Cook
Senior Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
From: Koha-devel mailto:koha-devel-boun...@lists.koha-community.org> > On Behalf Of Tomas Cohen
Arazi
Sent: Thursday, June 22, 2023 3:48 AM
To: koha-devel@lists.koha-community.org
<mailto:koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] Dockerized Koha
Hi all. We actually *have* a Docker image building pipeline [1]. If someone
wants to join the effort of publishing an official docker image, please put it
in the Roadmap wiki. That reminds me I didn't send the email about the roadmap
last week. Doing it right now.
Best regards.
[1] https://gitlab.com/koha-community/docker/koha-docker
El mié, 21 jun 2023 a las 4:12, Thomas Klausner (mailto:d...@plix.at> >) escribió:
Hi!
On Wed, Jun 21, 2023 at 11:05:56AM +1000, David Cook wrote:
> Do we have any appetite for starting to create a production-ready Dockerized
> Koha?
++
And while I have a lot of experience with deploying Perl apps using
containers like Docker or Podman, I did not manage to get a (usable)
Dockerfile / docker-compose for Koha running (in a reasonable amount of
time; and then discovered koha-testing-docker for localdev..)
But I could definitely again try to spend some time on this!
Greetings,
domm
--
#!/usr/bin/perl https://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&$_.$/}
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
<mailto:Koha-devel@lists.koha-community.org>
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/
--
Tomás Cohen Arazi
Theke Solutions (https://theke.io)
✆ +54 9351 3513384
GPG: B2F3C15F
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/
Re: [Koha-devel] Dockerized Koha
Personally, I don’t need it at the moment, although I briefly thought I might
for one library.
Sometimes I wonder about design…
1. Would it be 1 Koha instance per container, or would it be a
multi-tenant Koha in 1 container?
2. *How would upgrades be handled?*
a. At the moment, when you install a new package, post-install hooks
upgrade the database and change some configuration files. But that wouldn’t
work if you install the package when making a new Docker image. Those hooks
wouldn’t be invoked on the production system when you launch a new container
from the new image.
i. The
solution there might be to make a new script for performing upgrades, and for
backwards compatibility it would still be called by the DEB post-install hooks,
and the Docker entrypoint.sh could call it at startup time.
1. Although if it were called at startup time, that could make startup
unnecessarily slow, since the database upgrade check is very slow even when it
has no work to do. (I have been meaning to fix that…)
2. How would configuration files be persisted?
a. If you have 1 Koha instance per container, you could just mount
individual files, but there are a lot of configuration files, so that might get
burdensome.
b. If you have multi-tenant Koha, maybe you could mount the entirety of
/etc/koha/sites. That would probably work well.
i. I don’t
think you could mount /etc/koha because a lot of those files are generated by
the koha-common package at install time, so you’d want to pick them up from the
Docker image.
4. How would other files be persisted?
a. Mount to /var/lib/koha, /var/spool/koha, /var/log/koha(?)
Anything else I’ve missed?
David Cook
Senior Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
From: Koha-devel On Behalf Of
Tomas Cohen Arazi
Sent: Thursday, June 22, 2023 3:48 AM
To: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] Dockerized Koha
Hi all. We actually *have* a Docker image building pipeline [1]. If someone
wants to join the effort of publishing an official docker image, please put it
in the Roadmap wiki. That reminds me I didn't send the email about the roadmap
last week. Doing it right now.
Best regards.
[1] https://gitlab.com/koha-community/docker/koha-docker
El mié, 21 jun 2023 a las 4:12, Thomas Klausner (mailto:d...@plix.at> >) escribió:
Hi!
On Wed, Jun 21, 2023 at 11:05:56AM +1000, David Cook wrote:
> Do we have any appetite for starting to create a production-ready Dockerized
> Koha?
++
And while I have a lot of experience with deploying Perl apps using
containers like Docker or Podman, I did not manage to get a (usable)
Dockerfile / docker-compose for Koha running (in a reasonable amount of
time; and then discovered koha-testing-docker for localdev..)
But I could definitely again try to spend some time on this!
Greetings,
domm
--
#!/usr/bin/perl https://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&$_.$/}
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
<mailto:Koha-devel@lists.koha-community.org>
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/
--
Tomás Cohen Arazi
Theke Solutions (https://theke.io)
✆ +54 9351 3513384
GPG: B2F3C15F
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/
[Koha-devel] Dockerized Koha
Hi all, I've noticed a few people asking about Koha in Docker in production lately. Do we have any appetite for starting to create a production-ready Dockerized Koha? 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/
Re: [Koha-devel] Synchronizing a Koha database with kohastructure.sql (Bug 34064)
I thought about using the DBIx::Class files, but that gets messy on a server with many Koha databases, which all have their own upgrade histories. The DBIx::Class files also don't include all database information. I wanted a solution that could analyse and compare for me in a production environment without needing any cleanup. 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: Marcel de Rooy Sent: Tuesday, June 20, 2023 9:08 PM To: David Cook ; 'koha-devel' Cc: 'Tomas Cohen Arazi' ; 'Jonathan Druart' Subject: Re: Synchronizing a Koha database with kohastructure.sql (Bug 34064) We already have misc/devel/update_dbix_class_files.pl. Copy your Koha/Schema/Result before running. Or run it on a gitified install. Compare changes. _ Van: David Cook mailto:dc...@prosentient.com.au> > Verzonden: dinsdag 20 juni 2023 06:36 Aan: 'koha-devel' mailto:koha-devel@lists.koha-community.org> > CC: Marcel de Rooy mailto:m.de.r...@rijksmuseum.nl> >; 'Tomas Cohen Arazi' mailto:tomasco...@theke.io> >; 'Jonathan Druart' mailto:jonathan.dru...@bugs.koha-community.org> > Onderwerp: Synchronizing a Koha database with kohastructure.sql (Bug 34064) Hi all, I think we've all encountered issues with a Koha database being out of sync with kohastructure.sql, and it's not a fun experience to have. Today, I ran into items.paidfor columns that have survived long past a 20.11.00 upgrade. While looking to resolve that across all my instances, I was thinking how there could be other quirks as well, so I thought it would be nice to have an audit script: "Bug 34064 - Compare kohastructure.sql against current database using database audit script" It's not 100% perfect, but it does a very good job of detecting differences between a live Koha database and kohastructure.sql, and provides suggestions on how to remedy the database. It could be further improved, but I'm quite happy with this first draft. I'd like to be able to run it using koha-foreach to get a sense of how in-sync my Koha databases are on a server. 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] Synchronizing a Koha database with kohastructure.sql (Bug 34064)
Hi all, I think we've all encountered issues with a Koha database being out of sync with kohastructure.sql, and it's not a fun experience to have. Today, I ran into items.paidfor columns that have survived long past a 20.11.00 upgrade. While looking to resolve that across all my instances, I was thinking how there could be other quirks as well, so I thought it would be nice to have an audit script: "Bug 34064 - Compare kohastructure.sql against current database using database audit script" It's not 100% perfect, but it does a very good job of detecting differences between a live Koha database and kohastructure.sql, and provides suggestions on how to remedy the database. It could be further improved, but I'm quite happy with this first draft. I'd like to be able to run it using koha-foreach to get a sense of how in-sync my Koha databases are on a server. 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] Inventory improvements
Hi all, It's probably not the right time of year for inventory.pl improvements, but I've got a raft of changes for improving inventory.pl: Bug 31744 - Inventory tool can take a long time and never complete Bug 33989 - Inventory tool performs unnecessary authorized value lookups Bug 34051 - Koha::AuthorisedValues->get_description_by_koha_field not caching results for non-existent values If you dislike how slow inventory.pl is and how it has a tendency to timeout in managed IT environments, then you'll probably like these changes. I've applied the first 2 locally, and my librarians are much happier as a result. 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/
Re: [Koha-devel] Conflict between libossp-uuid-perl and libdata-uuid-perl
Hi Nigel, I've bumped into this conflict before (https://irc.koha-community.org/out.pl?channel=koha;date=2023-01-11). The libdata-uuid-perl package is required by libtest-dbix-class-perl, which is required for the koha-common package, although it really shouldn't be... we haven't gotten around to separating out the dependencies. Locally, what I do is patch debian/control and generate my own Debian packages, but that may or may not be an option for you. Unfortunately, the shortest path for you might be to move one of your systems to a different machine, but this is a topic that certainly needs some work... 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 On Behalf Of Nigel Titley Sent: Friday, 16 June 2023 3:12 AM To: koha-devel Subject: [Koha-devel] Conflict between libossp-uuid-perl and libdata-uuid-perl I'm currently running 22.05.13-1 (oldoldstable) on Ubuntu Focal and I'm trying to update to 22.11.06-3 (oldstable) and perhaps eventually to stable However I'm getting the following complaint from apt The following packages have unmet dependencies: libossp-uuid-perl : Conflicts: libdata-uuid-perl E: Broken packages As far as I can see the sympa package depends on libossp-uuid-perl and koha depends on libdata-uuid-perl Before I start the laborious process of moving either Koha or Sympa to a different machine can anyone suggest a fix? It looks like koha introduced a dependency on libdata-uuid-perl between oldoldstable and oldstable Thanks for any help that anyone can offer Nigel ___ 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] Long-running inventory.pl causing timeout? There's a solution...
Hi all, I imagine everyone has encountered situations where a long-running inventory.pl has caused a timeout? Well, at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31744 I have a solution (ie workaround). It requires running inventory.pl in CGI mode and without compression, so that it can stream null data out until the actual inventory output is ready. This prevents proxies from timing out while waiting for the inventory to process and print out its output. It works for both HTML and CSV output too. Ideally, it would be nice to have inventory.pl process in the background, but I think this is a very practical workaround that keep inventory.pl working until we can implement that more ideal solution. I'm going to have some libraries test the solution behind their corporate HTTP forward proxies and I'll let folks know on Bugzilla how that goes. I'm optimistic since all my testing has gone well so far. 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] Useful fix for client IP address in plack.log for anyone running Koha behind a proxy
Hi all, Koha::Middleware::RealIP gives you the real client IP address in the Koha code when running Koha behind a proxy. However, I noticed that this real client IP address wasn't showing up in plack.log, and it really started to bug me. I discovered that Koha::Middleware::SetEnv was compromising the flow of the $env variable through the Plack middlewares, but I've fixed it: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33967 It was a crazy-making problem, but it was a very simple fix, and it will make your plack.log files much more useful. Simple yet comprehensive test plan too, so I hope that folk take a look at it. 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] Integrating MarcEdit on Linux with Koha
Hi all, Recently, I've been running the MarcEdit CLI tool cmarcedit.exe on Linux (using mono) to run task automations that were created by librarians using MarcEdit on Windows. I'm hoping to put together a Koha plugin to allow librarians to upload the tasks and choose which Koha MARC records to run them on. (In this case, it will be for export purposes rather than in-place updates, but easy enough for someone to change.) Does anyone think that sounds interesting? (Once the Koha REST API builds up a bit more for biblios/items and search, I was thinking of getting in touch with Terry Reese to see about improving the Koha integration in MarcEdit as well.) 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/
Re: [Koha-devel] Rewrite of URLs, flushing all empty arguments
First things first, Philippe, you haven’t given enough information about the problem. For instance: http://localhost:8081/cgi-bin/koha/tools/letter.pl?op=delete_confirm <http://localhost:8081/cgi-bin/koha/tools/letter.pl?op=delete_confirm==suggestions=ACCEPTED> ==suggestions=ACCEPTED http://localhost:8081/cgi-bin/koha/tools/letter.pl?op=delete_confirm <http://localhost:8081/cgi-bin/koha/tools/letter.pl?op=delete_confirm=suggestions=ACCEPTED> =suggestions=ACCEPTED On koha-testing-docker, which admittedly is a later version, neither of these raise an error, although the second link won’t work as expected. So you should look at the actual error message in your log, and try to work it out from there. It might be that it’s a known issue that’s been fixed upstream already. Not sure what you mean by “the connection page”. Is that the login screen for letter.pl or something else? When you say “the branchcode= disappears on landing”, it’s not clear what you mean. Take a look at the Network tab on your browser and see if there are any redirects. You can also increase the logging on your Apache to see what exactly it’s doing: https://httpd.apache.org/docs/2.4/mod/core.html#loglevel. Maybe that problem instance has some Javascript running that is interfering with the location URL. You can add breakpoints in your browser so that it pauses at certain points in the process of loading. My suggestion would be doing some hands-on troubleshooting. Work the problem. The truth is out there. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Michael Hafen Sent: Thursday, 8 June 2023 7:17 AM To: Philippe Blouin Cc: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Rewrite of URLs, flushing all empty arguments There are many layers interacting here. First is apache recieving the request, where it passes through any apache modules that are loaded, then it's passed to cgi or fcgi (you haven't mentioned whether you have plack enabled, but you probably do), then it's passed to Koha's codebase. There could be version differences between Debian and Ubuntu in either Apache modules or Perl CGI/FCGI modules that would cause an empty get variable to be dropped. The perl module versions would be the first thing I'd check. On Wed, Jun 7, 2023 at 3:10 PM Philippe Blouin mailto:philippe.blo...@inlibro.com> > wrote: Hello all! New issue (in 22.05 here, but might be anywhere): <https://v22-test-intranet.hapax.inlibro.net/cgi-bin/koha/tools/letter.pl?op=delete_confirm> https://somedomain.net/cgi-bin/koha/tools/letter.pl?op=delete_confirm==suggestions=ACCEPTED When somedomain is onto one of our debian box (bullseye, 11), the branchcode= disappears on landing. Be it on the connection page or letter.pl <http://letter.pl> , we do not have the branchcode= anymore, and the code throws an error (branchcode being undefined) When running onto our laptops (Ubuntu) that doesn't happen. We have no custom RewriteRule, so I'm trying to figure out WHERE this rewrite comes from. All suggestions welcomed, Best regards, -- Philippe Blouin, Directeur de la technologie Tél. : (833) 465-4276, poste 230 philippe.blo...@inlibro.com <mailto:philippe.blo...@inlibro.com> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com> ___ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : 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@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] Configuration inheritance/override
Hi all, I think that we've all noticed that it's easy to add a new configuration item to koha-conf.xml for new instances, but that it's much harder to update koha-conf.xml when upgrading existing instances. A strategy that I (and others) have used on other projects is to have a core/base configuration file with defaults, and then the local config file is used to override those defaults on a per-instance basis. The core/base config file can be replaced as part of a Debian package upgrade, and it can be used to push out updated configuration to all instances with 1 click. This methodology also means that the local config file can often be fairly small too as it's only overriding specific configuration items. Anyway, it's easier said than done for Koha, but it's a thought, especially as we move forward. I know this is a problem that we bump into often in Koha and it would help to solve it. 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/
Re: [Koha-devel] A case against our release dates
I think that it never hurts to review an established tradition! In the southern hemisphere, I often catch up on a lot of work in December as many clients go on holiday early, and then I have my summer holidays in January. In April, I’ll take the latest point release of the November version (e.g. XX.11.03), and base local work off that, since it’s new but not *too new* (ie buggy). If the community did releases in February/March and August/September… I’d probably use the August/September release as my local code base for February-April since February/March would be “too new”/bleeding edge for me. Of course, August/September is right after northern hemisphere summer holidays… which might mean it’s a smaller release or it’s less stable as it has fewer eyes on it… And if the release was in February/March, would Hackfest be about setting the path for the next cycle, or would it be fixing all the bugs in the release that just came out a few weeks earlier? Would December Christmas holidays negatively impact a February/March release? Maybe it’s just human nature to leave big changes too close to the release date? We always think there will be lots of time, and then we rush to do things at the last minute? In any case, I think it’s worthwhile reviewing what we’re doing. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Tomas Cohen Arazi Sent: Friday, 2 June 2023 1:52 AM To: Philippe Blouin Cc: koha-devel Subject: Re: [Koha-devel] A case against our release dates My personal feeling is we should have a release right before the hackfest. So the hackfest sets the path for the next cycle. That could mean moving the hackfest a couple a bit later too Add for the second part of the year, I'm not sure yet. I just have the perception everyone is out in the months we are expected to do the bigger changes, and we end up doing them close to the release date. El jue, 1 jun 2023 12:46, Philippe Blouin mailto:philippe.blo...@inlibro.com> > escribió: Of course I'm coming with my northern hemisphere perspective, and have no horse in the race really as being far from RM, but I always thought those dates were the best available. Seems earlier (04, april) makes it closer to the hackfest you referred. Later makes it closer to summer holidays. Were you considering breaking the equal split in time, having a small and a big release each year? November for the big, and march for the small, the hackfest starting the next cycle ? Thinking outside the box... Philippe Blouin, Directeur de la technologie Tél. : (833) 465-4276, poste 230 philippe.blo...@inlibro.com <mailto:philippe.blo...@inlibro.com> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com> On 2023-06-01 07:35, Tomas Cohen Arazi wrote: Hi all. Having served as Release Manager for the project a couple times, I'd like to ask y'all to think about the dates we've chosen and have stuck to the last few years for our releases. I know they are somehow aligned with our regular yearly meetings, and one each semester. But my experience says: - We all want to implement things we discuss in the Hackfest, but the release is too close. So we either push too late in the cycle, or need to cool down our brains/ideas for 'after the release in two months'. - The other scenario, which I suffered a lot recently (and will soon) is summer holidays in the northern hemisphere: you're all out when we should be pushing the riskier things to have enough time to fix things, and we end up rushing things... on the last third of the cycle. I don't have a proposal right now, but wanted to say my perception is the dates are not ideal as-is. And hear back from you all. Cheers! -- Tomás Cohen Arazi Theke Solutions (http://theke.io <http://theke.io/> ) ✆ +54 9351 3513384 GPG: B2F3C15F ___ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> 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] Unable to access plack middleware ( Plack::Middleware::Prometheus::RequestTimes )
That’s cool. I’ve been wanting to integrate with Prometheus for years but never had the time. In this case, did you remember to add a ProxyPass in /etc/koha/apache-shared-intranet-plack.conf for the /metrics path? David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Kyle Hall Sent: Wednesday, 31 May 2023 2:37 AM To: Koha Devel Subject: [Koha-devel] Unable to access plack middleware ( Plack::Middleware::Prometheus::RequestTimes ) Hey yinz, I’m trying to add some Prometheus metrics to Koha. This looks like it has what we want: https://metacpan.org/pod/Plack::Middleware::Prometheus::RequestTimes Really, I’d like response times per script, but I’m not that picky just yet. I tried this on /etc/koha/plack.psgi but I just get a 404 for 127.0.0.1:8081/metrics <http://127.0.0.1:8081/metrics> . No errors in the logs. Any thoughts? Here's my POC commit: https://github.com/bywatersolutions/bywater-koha-devel/commit/472436f7a05a8ae5049cd8f140ba43e8a71bce8c --- http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) ___ 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] Noticed "Ad by EthicalAds" for CKAN
Hi all, I was on an open source software documentation site when I noticed an ad that described itself as "Ad by EthicalAds": https://docs.ckan.org/en/2.10/user-guide.html#what-is-ckan I heard about CKAN years ago, and recently I've been using it to get open data from the Australian government for a project. So it's not a scam project. I found it interesting that they had advertising. Now I'm not saying it would be right for Koha, but I thought it was an interesting thing to observe and I thought I'd share it with you all. 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/
Re: [Koha-devel] Placing multiple record-level holds on a record
Hi Emily, Thanks for getting in touch. You're right about Koha not having the ability to place multiple item level holds at the same time. There is a bug report for it https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15565 but holds are a notoriously difficult area to change so it's never made it through into Koha, unfortunately. I think the libraries really interested in that functionality might need to get together to sponsor its further work. 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: Lamancusa, Emily Sent: Tuesday, 23 May 2023 11:17 PM To: David Cook ; 'Katrin Fischer' ; koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Placing multiple record-level holds on a record Hi David, Just want to weigh in that our library system does use the ability to place multiple record-level holds for staff-run book discussion programming. (We don't use the Clubs module because for us they are open programs, not clubs with a specific membership list.) We have the circulation rules set to allow multiple record-level holds for staff cards only, so that staff can easily place multiple holds for programming purposes, but customers are still limited to 1 hold per record unless a staff member makes the judgment call to override that limit. I'm not sure that there's a strong reason to use record-level holds instead of item-level holds for that situation, except that, as far as I can tell, Koha does not yet have any multi-select feature (e.g. checkboxes instead of radio buttons) for placing holds on multiple items in a single form submission, correct? Which means that staff can place 20 record-level holds with a few clicks, but need to place 20 item-level holds individually. (I'd love to be told I'm wrong about this, though!) Emily Lamancusa (she/her) IT Specialist III Montgomery County Public Libraries (240) 777-0052 _ From: David Cook mailto:dc...@prosentient.com.au> > Sent: Monday, May 22, 2023 7:29 PM To: 'Katrin Fischer' mailto:katrin.fischer...@web.de> >; koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> mailto:koha-devel@lists.koha-community.org> > Subject: Re: [Koha-devel] Placing multiple record-level holds on a record Hi Katrin, But I think the intention of "Holds per record (count)" was to enable multiple item-level holds rather than multiple record-level holds? https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14695 I suppose one could argue though that record-level holds are ultimately still for items. but (depending on your rules) you can place 1+ record-level holds on a record with only 1 item (e.g. I have 10 holds on 1 record that has 1 item). If you have item-level holds, you can only ever place 1 item-level hold on that 1 item. It looks like a loophole/flaw to me. You can also place holds on items you already have checked out which seems weird. (I think it's probably due to the syspref AllowHoldsOnPatronsPossessions although I think the intention there was probably to allow holds on other items belonging to that record.) I haven't thoroughly tested it, but I think in theory you could monopolize an item for longer than a library intends if the circ rules were loose. I suppose I was just wondering if these are intentional or accidental behaviours. Holds are tricky though. What I might see as a bug might be a feature to someone else. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel mailto:koha-devel-boun...@lists.koha-community.org> > On Behalf Of Katrin Fischer Sent: Monday, 22 May 2023 3:19 PM To: koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Placing multiple record-level holds on a record hi David, it depends, there is definitely a feature to do that. If you can place multiple per record is defined in the circulation rules. If holds per record is 1, you should of course not be able to. It's been there for multiple versions now. Hope that helps, Katrin On 22.05.23 06:46, David Cook wrote: Hi all, I'm noticing in 22.11 that it's possible to place multiple record-level holds on a record. Do you think that's intentional? While I can understand having multiple item-level holds, having multiple record-level holds seems like a way to game the system. 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 <mailto:Koha-devel@lists.koha-community.org> https://li
Re: [Koha-devel] Azure configuration for OAuth authentication with Koha
Hi Alex, Well, the good news is that OIDC is just a wrapper around OAuth2, so a lot of the same things apply either way. But my experience using only OAuth2 for AuthN is pretty limited. Previously, I've reviewed how Keycloak integrates with OAuth2 endpoints for things like Facebook: https://github.com/keycloak/keycloak/blob/main/services/src/main/java/org/keycloak/social/facebook/FacebookIdentityProvider.java Sounds like you're making progress though. 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: Alex Buckley Sent: Monday, 22 May 2023 3:23 PM To: David Cook ; 'koha-devel' Subject: Re: [Koha-devel] Azure configuration for OAuth authentication with Koha Hi David, Ah that might be the problem! The client is using OAuth with Azure currently. We have indeed set up using OIDC with Azure before, but we haven't used OAuth before with any identity providers. Thanks for raising that. Are you aware of what IdP OAuth should be used with? Kind regards, Alex On 22/05/23 11:27, David Cook wrote: > Hi Alex, > > Do you mean OAuth or OIDC? With Azure you'd want to be using OIDC which I > think you folk have set up before with Azure? > > When it comes to the URIs you register, you'll want to use a * wildcard at > the end of the OpacBaseURL, so that the users are able to login from any page > in the Koha OPAC. > > 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 On > Behalf Of Alex Buckley > Sent: Monday, 22 May 2023 6:26 AM > To: koha-devel > Subject: [Koha-devel] Azure configuration for OAuth authentication > with Koha > > Hi Koha community, > > If you have configured Koha OAuth authentication with Azure could you please > let me know what did you configure as the Redirect and Reply URIs in Azure? > > Context: We have a library (running Koha 22.11) that is trying to setup OAuth > authentication with Azure. > > They have configured the Koha end using the new Koha 'Administration' > > 'Identity provider' pages. > > When this library attempt a SSO login they get a 'AADSTS00113: No reply > address is registered for the application' Azure error - see attached. > > Should the Redirect and Reply URIs in Azure just be the Koha OpacBaseURL > (with https), or something else? > > Thanks so much, > > Alex > -- Alex Buckley Koha Developer | Implementation Lead Catalyst.Net Limited - Expert Open Source Solutions Catalyst.Net Limited - a Catalyst IT group company CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267. ___ 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] Placing multiple record-level holds on a record
Hi Katrin, But I think the intention of “Holds per record (count)” was to enable multiple item-level holds rather than multiple record-level holds? https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14695 I suppose one could argue though that record-level holds are ultimately still for items… but (depending on your rules) you can place 1+ record-level holds on a record with only 1 item (e.g. I have 10 holds on 1 record that has 1 item). If you have item-level holds, you can only ever place 1 item-level hold on that 1 item. It looks like a loophole/flaw to me. You can also place holds on items you already have checked out which seems weird. (I think it’s probably due to the syspref AllowHoldsOnPatronsPossessions although I think the intention there was probably to allow holds on other items belonging to that record.) I haven’t thoroughly tested it, but I think in theory you could monopolize an item for longer than a library intends if the circ rules were loose. I suppose I was just wondering if these are intentional or accidental behaviours. Holds are tricky though. What I might see as a bug might be a feature to someone else… David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Katrin Fischer Sent: Monday, 22 May 2023 3:19 PM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Placing multiple record-level holds on a record hi David, it depends, there is definitely a feature to do that. If you can place multiple per record is defined in the circulation rules. If holds per record is 1, you should of course not be able to. It's been there for multiple versions now. Hope that helps, Katrin On 22.05.23 06:46, David Cook wrote: Hi all, I’m noticing in 22.11 that it’s possible to place multiple record-level holds on a record. Do you think that’s intentional? While I can understand having multiple item-level holds, having multiple record-level holds seems like a way to game the system… 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 <mailto: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] TLS connections
Hi Jacob, Most servers should already be using TLS 1.2, and all modern browsers should support it, so it’s all good. As for the ISBD, in terms of display, you could use custom XSLTs to change the display, but a maintenance burden would come with that for you. I don’t think there’s a way to transform metadata at export time. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Jacob Jett Sent: Tuesday, 23 May 2023 12:59 AM To: koha-devel@lists.koha-community.org Subject: [Koha-devel] TLS connections Hi gang, It looks like AWS is upgrading their TLS connections from 1.0/1.1 to 1.2. Does anyone know if this will impact Koha records that point at AWS objects? Unrelated ISBD punctuation question. I've had some complaints from my staff about displaying ISBD punctuation. We use it in MARC to make sure that the metadata records are portable across multiple languages. However, I can sympathize that it doesn't look very clean in the display. Is there a Koha widget that either, let's us suppress displaying the ISBD punctuation or implements it at metadata record export time? Regards, Jacob Jacob Jett | Research Librarian | ASFPM 8301 Excelsior Dr. | Madison, WI 53717 tel: 608-828-3000 | desk: 608-828-6342 | <http://www.floods.org/> floods.org | Email Jacob <mailto:ja...@floods.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] Placing multiple record-level holds on a record
Hi all, I'm noticing in 22.11 that it's possible to place multiple record-level holds on a record. Do you think that's intentional? While I can understand having multiple item-level holds, having multiple record-level holds seems like a way to game the system. 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/
Re: [Koha-devel] Azure configuration for OAuth authentication with Koha
Hi Alex, Do you mean OAuth or OIDC? With Azure you'd want to be using OIDC which I think you folk have set up before with Azure? When it comes to the URIs you register, you'll want to use a * wildcard at the end of the OpacBaseURL, so that the users are able to login from any page in the Koha OPAC. 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 On Behalf Of Alex Buckley Sent: Monday, 22 May 2023 6:26 AM To: koha-devel Subject: [Koha-devel] Azure configuration for OAuth authentication with Koha Hi Koha community, If you have configured Koha OAuth authentication with Azure could you please let me know what did you configure as the Redirect and Reply URIs in Azure? Context: We have a library (running Koha 22.11) that is trying to setup OAuth authentication with Azure. They have configured the Koha end using the new Koha 'Administration' > 'Identity provider' pages. When this library attempt a SSO login they get a 'AADSTS00113: No reply address is registered for the application' Azure error - see attached. Should the Redirect and Reply URIs in Azure just be the Koha OpacBaseURL (with https), or something else? Thanks so much, Alex ___ 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] Issues sending a JSON request body in a GET request to REST API
In the short term, it appears I've forgotten about the "q" parameter. It
takes an unencoded argument, so that's getting me where I need to go.
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: David Cook
Sent: Friday, 12 May 2023 4:47 PM
To: 'Koha Devel'
Subject: Issues sending a JSON request body in a GET request to REST API
Hi all,
With the Koha REST API, there's "Advanced Matching" which uses a JSON body
in a GET request:
curl -u koha:koha --request GET 'http://127.0.0.1:8081/api/v1/patrons/'
--header "Content-Type: application/json" --data-raw '{ "-or": [ {
"surname": { "-like": "Acev%" } }, { "firstname": { "-like": "Hen%" } } ] }'
https://wiki.koha-community.org/wiki/Koha_REST_API_Users_Guide#Advanced_Matc
hing
While this technically works, we really shouldn't be sending a JSON request
body in a GET request.
I'm working on a third-party system, and it's actually preventing me from
sending GET requests with request bodies (since GET requests aren't supposed
to have request bodies), so I can't actually use the API using that system's
built-ins. I'll have to code a workaround.
At some point, we should replace these GET requests with POSTed search
queries I think.
David Cook
Senior Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
___
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/
