<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body>A new request with request id 14009 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is : <br><br>Title : Koha-devel Digest, Vol 193, Issue 6<br>Category : <br>Description : <div>Send Koha-devel mailing list submissions to<br> koha-devel@lists.koha-community.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>or, via email, send a message with subject or body 'help' to<br> koha-devel-request@lists.koha-community.org<br><br>You can reach the person managing the list at<br> koha-devel-owner@lists.koha-community.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of Koha-devel digest..."<br><br><br>Today's Topics:<br><br> 1. Re: My dev list for 22.05 (Arthur)<br> 2. Re: My dev list for 22.05 (Paul Poulain)<br> 3. Re: My dev list for 22.05 (Tomas Cohen Arazi)<br> 4. Re: My dev list for 22.05 (Magnus Enger)<br> 5. Re: My dev list for 22.05 (Owen Leonard)<br> 6. Re: My dev list for 22.05 (Michael Hafen (TECH))<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Fri, 3 Dec 2021 12:03:21 +0100<br>From: Arthur <arthur.suzuki@biblibre.com><br>To: koha-devel@lists.koha-community.org<br>Subject: Re: [Koha-devel] My dev list for 22.05<br>Message-ID: <97c4ccd8-2d96-a038-09ea-a67dab1cf58e@biblibre.com><br>Content-Type: text/plain; charset=UTF-8; format=flowed<br><br>Friday's stone in the pond :)<br><br>Were you thinking like what is done today for MARC / UNIMARC / NORMAC, <br>choosing upon installation and then using one model?<br><br>Or more as "mixing different data-models in one Koha"?<br><br>That would need a column for storing the data model ID for each record <br>and somewhere to store each data-model definitions (linking to the <br>forementionned id).<br><br>This looks a bit like what we do for Bokeh.<br><br>Since we import records from different systems, we store the relation <br>between a record or item and it's system of origin.<br><br>We also store a mapping configuration for each system Bokeh is connected <br>to (be it several Koha of different configuration, several ILS, ILS + <br>online ressources, whatever combination...).<br><br>On 03/12/2021 11:00, Paul Poulain wrote:<br>> Hello all,<br>><br>> Regarding this topic : why not also investigate the new data models <br>> that will replace MARC ?<br>><br>> We store the data in original form (marcxml) and move to <br>> biblio/biblioitems a part of the data that is useful for basic <br>> operation (like getting the title and the author).<br>><br>> We could import different data models with the same mechanism (RDA, <br>> DC, ...). The biblio_metadata.format and schema fields were created <br>> with this idea in mind. That would require an additional layer for <br>> transforming format/schema to internal Koha and many more things, it's <br>> a long term goal.<br>><br>> Le 01/12/2021 à 12:55, Jonathan Druart a écrit :<br>>> 3. Merge biblio and biblioitem<br>>> Self-explanatory, merge the 2 tables to remove the unneeded 1-1<br>>> relation between them<br>><br><br><br>------------------------------<br><br>Message: 2<br>Date: Fri, 3 Dec 2021 15:20:11 +0100<br>From: Paul Poulain <paul.poulain@biblibre.com><br>To: koha-devel@lists.koha-community.org<br>Subject: Re: [Koha-devel] My dev list for 22.05<br>Message-ID: <cf4b8f4a-963a-a60f-423f-4deb97a944cd@biblibre.com><br>Content-Type: text/plain; charset=utf-8; format=flowed<br><br>Hello,<br><br>Le 03/12/2021 à 12:03, Arthur a écrit :<br>> Friday's stone in the pond :)<br>><br>> Were you thinking like what is done today for MARC / UNIMARC / NORMAC, <br>> choosing upon installation and then using one model?<br>nope<br>><br>> Or more as "mixing different data-models in one Koha"?<br>yes<br><br>-- <br>Paul Poulain, Associé-gérant / co-owner<br>BibLibre, Services en logiciels libres pour les bibliothèques<br>BibLibre, Open Source software and services for libraries<br><br><br><br>------------------------------<br><br>Message: 3<br>Date: Fri, 3 Dec 2021 11:32:28 -0300<br>From: Tomas Cohen Arazi <tomascohen@gmail.com><br>To: Jonathan Druart <jonathan.druart@bugs.koha-community.org><br>Cc: koha-devel <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] My dev list for 22.05<br>Message-ID:<br> <CABZfb=WSWCCpXpfsk3-9eCYMZgfSLTquB4HUYWtFEt_8vEjiUg@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>El mié, 1 dic 2021 a las 12:24, Jonathan Druart (<<br>jonathan.druart@bugs.koha-community.org>) escribió:<br><br>> Hello everybody,<br>><br>> I have been listing some tasks I would like to work on during the next<br>> development cycle.<br>> I suggest a give and take approach. Help me on one or more of those<br>> topics and I will help you as I can on whichever topic(s) you decide.<br>><br><br>Great!<br><br><br>> 2. Remove item-level_itype<br>> We have been discussing this one for a long time already, is it the<br>> time to tackle it down?<br>> See<br>> -<br>> https://lists.koha-community.org/pipermail/koha-devel/2015-December/042114.html<br>> - Bug 10385 - item-level_itypes checks need to be refactored<br>> - Bug 29106 - Can we get rid of Koha::Item->effective_itemtype<br>><br><br>I'm in!<br><br><br>> 3. Merge biblio and biblioitem<br>> Self-explanatory, merge the 2 tables to remove the unneeded 1-1<br>> relation between them<br>><br><br>I'm in!<br><br><br>> 4. Improve action logs<br>> We have had several changes and reports in this area lately. We could<br>> improve the way we log changes for easy tracking and comparaison.<br>> See<br>> - Bug 28714 - Bib record change tracking action log<br>> - Bug 29451 - Merging records and authorities - log details for the<br>> delete action so it could be recreated<br>> - Bug 28692 - Reduce DB action_log table size<br>><br>> I think we should add 2 new columns to log before and after the object<br>> is updated, serialized in JSON. We could then generate the diff on<br>> display.<br>><br><br>^^ this goes against the target goal for 28692. We should actually store<br>diffs!<br><br><br>> 5. Patron searches (holds and checkouts)<br>> Those two patron searches do not use the same code as the other patron<br>> searches.<br>> We should uniformize them.<br>> - Bug 29136 - Patron search on request.pl has performance and display<br>> issues<br>> - comment 37 of Bug 15812 - Checkout search with too many results<br>> (single character search) causes poor performance or timeout<br>> There is also bug 29125 (Use Koha::Patron object in<br>> C4:Utils::DataTables::Members.pm) that is removing the SQL query to<br>> use Koha::Patrons.<br>><br><br>I'm happy to help. I suggest we explore using the API, that has pretty<br>efficient queries (it automatically prefetches related objects, etc).<br><br><br>> 5. Async ES indexation<br>> Now that we have the task queue we should use it to index the records<br>> and don't index them in a synchronous way.<br>> Bug 27344 - Implement Elastic's update_index_background using<br>> Koha::BackgroundJob<br>> If we don't want to use the task queue for that purpose we should<br>> provide another solution.<br>> To be discussed and implemented (or validate and test the patches that<br>> are already on bug 27344)<br>><br><br>We should move both ES and Zebra indexing to the task_queue. I'm in!<br><br><br>> 8. Move C4 and Koha to lib<br>> We discussed that earlier and I even attached patches to bug 28589. I<br>> don't think it's top priority but I can dedicate some hours if some of<br>> you think it is a move we must do now.<br>><br><br>We could go crazy and put all the intranet stuffs together as well :-D<br><br><br>> And also, what's on your list for 22.05?<br>><br><br>We need help with the ongoing discussion on<br>https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29523 and<br>friends. We need a performant solution and consensus on the approach, as it<br>will impact how the API is/can be used.<br><br>I would like to see the holds table merge pushed early and help is needed<br>there.<br><br>I want to move more pages into using the API, especially those using<br>DataTables.<br><br>Best regards<br><br>-- <br>Tomás Cohen Arazi<br>Theke Solutions (http://theke.io)<br>✆ +54 9351 3513384<br>GPG: B2F3C15F<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20211203/e9014f13/attachment-0001.htm><br><br>------------------------------<br><br>Message: 4<br>Date: Fri, 3 Dec 2021 15:46:56 +0100<br>From: Magnus Enger <magnus@libriotech.no><br>To: koha-devel@lists.koha-community.org<br>Subject: Re: [Koha-devel] My dev list for 22.05<br>Message-ID: <99e49387-9836-5501-e0d7-929830943f97@libriotech.no><br>Content-Type: text/plain; charset=utf-8; format=flowed<br><br>Bonjour!<br><br>Den 03.12.2021 11:00, skrev Paul Poulain:<br>> Hello all,<br>> <br>> Regarding this topic : why not also investigate the new data models that <br>> will replace MARC ?<br>> <br>> We store the data in original form (marcxml) and move to <br>> biblio/biblioitems a part of the data that is useful for basic operation <br>> (like getting the title and the author).<br>> <br>> We could import different data models with the same mechanism (RDA, DC, <br>> ...). The biblio_metadata.format and schema fields were created with <br>> this idea in mind. That would require an additional layer for <br>> transforming format/schema to internal Koha and many more things, it's a <br>> long term goal.<br><br>Yeah, that would be an awesome development!<br><br>Best regards,<br>Magnus<br>Libriotech<br><br><br>------------------------------<br><br>Message: 5<br>Date: Fri, 3 Dec 2021 10:51:04 -0500<br>From: Owen Leonard <oleonard@myacpl.org><br>To: koha-devel <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] My dev list for 22.05<br>Message-ID:<br> <CAO4qe2P=NO4vMHq4LsPXEPrv=AqmaWzHqVdc+zRORzdrEeF2cg@mail.gmail.com><br>Content-Type: text/plain; charset="UTF-8"<br><br>> And also, what's on your list for 22.05?<br><br>Some larger things I'm working on:<br><br>- Upgrading jQuery in the OPAC and staff client. This depends on<br>upgrading jQueryUI which depends on getting the last of the Flatpickr<br>patches in.<br>- Continue to replace jQueryUI widgets with alternatives, starting<br>with features available in Bootstrap<br>- Update Bootstrap in the staff client. It currently uses v.3 and<br>Bootstrap is currently on v.5.1. Not sure if this one is too big to<br>finish for 22.05!<br><br>-- Owen<br><br><br>------------------------------<br><br>Message: 6<br>Date: Fri, 3 Dec 2021 11:13:47 -0700<br>From: "Michael Hafen (TECH)" <michael.hafen@washk12.org><br>Cc: koha-devel@lists.koha-community.org<br>Subject: Re: [Koha-devel] My dev list for 22.05<br>Message-ID:<br> <CAAh7Udm01k+7=5Y12fVazNsD+gBGS03itPf0osPMCyZ-ZPk+yQ@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>If I may throw another stone in this pond... ;)<br><br>I think it would be interesting to flip the relationship between the<br>biblio/biblioitems/items tables and the marcxml data. Using the<br>biblio_metadata table we could store every piece of information necessary<br>to generate marcxml from there and the biblio/biblioitems/items tables.<br>This would make those tables authoritative.<br><br>We could even go as far as not storing the marcxml, but generating it on<br>the fly as necessary. We could take this a step farther and use the<br>marc_*_structure tables to represent which ever model we want to support by<br>adding a format indicator; for example specifying a set of tag/subfield<br>rows as being for UNIMARC, and then any data coming in to or going out from<br>Koha in that format would go from the<br>biblio/biblioitems/items/biblio_metadata through the marc_*_structure (koha<br>to marc mappings) to UNIMARC, or visa-versa.<br><br>The biblio and item edit screens would likewise use the<br>biblio/items/biblio_metadata tables instead of the marcxml data. This<br>would make imports, exports, and search engine updates more complicated, as<br>the MARC format data would have to be generated on the fly. The trade off<br>is that everything else in Koha could become less complicated as it would<br>all reference the biblio/items/biblio_metadata tables directly without<br>having to decode / encode MARC in the system format. The difference in<br>complexity is small, but it is there. In addition, all the record data<br>would be available directly through sql without having to go through<br>extracting data from marcxml for some things.<br><br>Admittedly, this is a very extreme idea compared to how Koha works now.<br>But it bugs me a little that we have two copies of each record ( in the<br>biblio/items tables and in the marcxml ), and have to take care to make<br>sure they are kept up to date with each other.<br><br>Anyway, there's an idea, since we're talking about future developments and<br>supporting data formats besides MARC.<br><br><br>On Fri, Dec 3, 2021 at 7:20 AM Paul Poulain <paul.poulain@biblibre.com><br>wrote:<br><br>> Hello,<br>><br>> Le 03/12/2021 à 12:03, Arthur a écrit :<br>> > Friday's stone in the pond :)<br>> ><br>> > Were you thinking like what is done today for MARC / UNIMARC / NORMAC,<br>> > choosing upon installation and then using one model?<br>> nope<br>> ><br>> > Or more as "mixing different data-models in one Koha"?<br>> yes<br>><br>> --<br>> Paul Poulain, Associé-gérant / co-owner<br>> BibLibre, Services en logiciels libres pour les bibliothèques<br>> BibLibre, Open Source software and services for libraries<br>><br>> _______________________________________________<br>> Koha-devel mailing list<br>> Koha-devel@lists.koha-community.org<br>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>> website : https://www.koha-community.org/<br>> git : https://git.koha-community.org/<br>> bugs : https://bugs.koha-community.org/<br>><br><br><br>-- <br>Michael Hafen<br>Washington County School District Technology Department<br>Systems Analyst<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20211203/5b710454/attachment.htm><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>Koha-devel mailing list<br>Koha-devel@lists.koha-community.org<br>https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>website : https://www.koha-community.org/<br>git : https://git.koha-community.org/<br>bugs : https://bugs.koha-community.org/<br><br><br>------------------------------<br><br>End of Koha-devel Digest, Vol 193, Issue 6<br>******************************************<br></div><br><br>NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.<br></body></html>