- Koha-devel - lists.koha-community.org

question about MARC 856 $e
by Jacob Jett 17 Oct '22

17 Oct '22

Hi gang, Some context, I'm asking these questions because our organization has been using the 856 $e field to display cover images to users searching the catalog. I have questions regarding this practice: 1) I see that the nature of 856 $e was changed to record data provenance metadata by the Library of Congress this year. Will there be a new place to use for linking cover images? E.g., is Koha going to be developing a specific 9XX field for the purpose or will there be a way for individual libraries to define a field that does the same thing as the pre-2022 856 $e did? (I'm assuming that an update that applies recent changes to MARC21 will eventually get globally pushed out.) 2) Accessibility and image alt text--is there a way to add alt text to the metadata such that accessibility widgets and software encountering images like shared cover images can grab the alt text for those images? Thank you in advance for your answers. Regards, Jacob *Jacob Jett* | Research Librarian | ASFPM 8301 Excelsior Dr. | Madison, WI 53717 tel: 608-828-3000 | desk: 608-828-6342 | floods.org <http://www.floods.org/> | *Email Jacob <jacob(a)floods.org>*

2 1

Koha 22.11 - Release dates
by Tomas Cohen Arazi 17 Oct '22

17 Oct '22

Hi all, this cycle has been very busy and all of a sudden, it is ending! This are the preliminary dates so you are aware of: * Oct 28th - "Soft" feature freeze, nothing big or with high risk of side-effects will be included into the final release if not marked as Passed QA * Nov 3-5 - "Hard" feature freeze, nothing considered as an improvement will be pushed if not marked as Passed QA * Nov 10th - String freeze, draft of release notes published * Nov 17th - Only bug fixes considered major, critical or blocker will be pushed * Nov 25th - Final release PM me if you have any comments. -- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F

1 0

Call for news - Newsletter October 2022
by Koha Newsletter 13 Oct '22

13 Oct '22

Hi I'm collecting news for the October 2022 Koha Community Newsletter. Please send anything noteworthy to: kohanews (at) gmail (dot) com News criteria: * News items can be of any length. * Images are fine. * Anything and everything Koha. * Submit by the 26th of the month. Text format criteria: * Just structured plain text, or * HTML text to include tables or similar For events: * Consider adding your event to the Koha Community calendar at https://koha-community.org/calendar/ Thank you! Michael Kuhn Editor, Koha Community Newsletter

1 0

Undoing workaround in BZ 30879 to replace with native Zebra function...
by David Cook 13 Oct '22

13 Oct '22

Hi all, BZ 30879 included a workaround to what we saw as a limitation in Zebra's sort functionality, but it turns out that there was an undocumented native Zebra alternative. Adam from Indexdata just told me about it in the last 12 hours. Since BZ 30879 hasn't gone out yet (and since it requires a full database re-index), I wonder if we should put a rush on BZ 31756 to replace the workaround with the native sort (which doesn't require a re-index). I'll be posting a patch shortly. 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

1 0

SpringShare LibGuides Custom Search Koha Plugin
by David Cook 13 Oct '22

13 Oct '22

Hi all, I've looked around and I haven't found any Koha Plugins that handle a SpringShare LibGuides Custom Search. Does anyone have one that I'm not seeing? Here's the details for a LibGuides Custom Search: https://ask.springshare.com/libapps/faq/700 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

1 0

Need help to update coding guidelines with the replacement of jQueryUI Datepicker with flatpickr
by Victor Grousset/tuxayo 12 Oct '22

12 Oct '22

Hi :) The coding guidelines still mention Datepicker. And we had a report that the change isn't straightforward and that some documentation would be useful. Any volunteer among the people who have a bit of understanding of the change and the usage? It had been suggestion to also have a ticket about this: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31741 Cheers, -- Victor Grousset/tuxayo

1 0

Should we support MySQL? (either 5.7 or 8.0)
by Victor Grousset/tuxayo 12 Oct '22

12 Oct '22

Hi :) The CI only tests MySQL 8 on main/master but it passes. Maybe we dropped strong support for MySQL years ago? And only kept MySQL 8 on master to catch the strict SQL mode issues? Because that's mostly how I hears about MySQL lately. (strict SQL mode) And I heard MySQL 5.7 still has the db increment issue so we likely don't want to support it. Cheers, -- Victor Grousset/tuxayo

1 0

enable automatic filesystem refresh in Plack - KTD
by Mason James 11 Oct '22

11 Oct '22

hi folks i recently added this feature to KTD - just master* images, for now it seems to be behaving itself; but pleeese comment in bug 31729, if you see a problem

1 0

Hiding records/items in OAI-PMH output
by David Cook 10 Oct '22

10 Oct '22

Hi Ere, There's been some discussion on Bug 31161 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31161 about hiding records/items in OAI-PMH output, and I was keen to get your thoughts. I've had a few different ideas over time, but right now I'm thinking that the best way to deal with hiding bib records is to mark them as "deleted" in the OAI-PMH feed. Firstly, it would be a very easy change to make, which would probably not affect performance much at all. Secondly, it would allow records that have been hidden to be removed from downstream systems automatically via OAI-PMH harvesters that support deletions. Since it's a small code change, I'm tempted to trial it locally using the OAI Config file to turn on this hiding mechanism. Since you're the person who has done the most work on the OAI-PMH server recently, I figured you'd be a good person to ask for feedback! 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

2 1

Re: [Koha-devel] Required Mojolicious versions in Koha
by David Cook 10 Oct '22

10 Oct '22

Thanks, guys. That was very helpful : ). When I work on customizing 22.11 in the new year, I’ll have a play with “skip_validating_specification” and let everyone know how it goes. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Tomas Cohen Arazi <tomascohen(a)theke.io> Sent: Thursday, 6 October 2022 11:40 AM To: Mason James <mtj(a)kohaaloha.com> Cc: David Cook <dcook(a)prosentient.com.au>; koha-devel <koha-devel(a)lists.koha-community.org>; Martin Renvoize <martin.renvoize(a)ptfs-europe.com> Subject: Re: Required Mojolicious versions in Koha You mean Mojolicious::Plugin::OpenAPI, right? The relevant pieces are - Mojolicious - JSON::Validator - Mojolicious::Plugin::OpenAPI on 22.05+ we jumped to the latest versions of the latter, shifting the Mojolicious version to achieve it, as well. Hope it clarified. BTW, we can now migrate the spec to OpenAPI V3 and take advantage of things like 'nullable' and inheritance to be more compliant. Best regards El mié, 5 oct 2022 20:39, Mason James <mtj(a)kohaaloha.com <mailto:mtj@kohaaloha.com> > escribió: On 6/10/22 12:31 pm, Mason James wrote: > > On 5/10/22 2:23 pm, David Cook wrote: >> >> Hi all, >> >> I’m trying to figure out what versions of Mojolicious and Mojolicious::Plugin::OpenAPI are really required for Koha as I’d like to start using the “skip_validating_specification” feature in Mojolicious::Plugin::OpenAPI which is available from version 4.0.3 onwards. >> > > as i understand: > koha 22.05 runs on openapi 2 > koha 22.11 runs on openapi 3+ > > more info on section 1.4 below.... > https://wiki.koha-community.org/wiki/REST_API_Debug > oops, typo :) koha 21.11 runs on openapi 2 koha 22.05 runs on openapi 3+

1 0