Re: [Koha-devel] My dev list for 22.05
> And also, what's on your list for 22.05? Some larger things I'm working on: - Upgrading jQuery in the OPAC and staff client. This depends on upgrading jQueryUI which depends on getting the last of the Flatpickr patches in. - Continue to replace jQueryUI widgets with alternatives, starting with features available in Bootstrap - Update Bootstrap in the staff client. It currently uses v.3 and Bootstrap is currently on v.5.1. Not sure if this one is too big to finish for 22.05! -- Owen ___ 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] My dev list for 22.05
Bonjour! Den 03.12.2021 11:00, skrev Paul Poulain: Hello all, Regarding this topic : why not also investigate the new data models that will replace MARC ? We store the data in original form (marcxml) and move to biblio/biblioitems a part of the data that is useful for basic operation (like getting the title and the author). We could import different data models with the same mechanism (RDA, DC, ...). The biblio_metadata.format and schema fields were created with this idea in mind. That would require an additional layer for transforming format/schema to internal Koha and many more things, it's a long term goal. Yeah, that would be an awesome development! Best regards, Magnus Libriotech ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
Re: [Koha-devel] My dev list for 22.05
El mié, 1 dic 2021 a las 12:24, Jonathan Druart (< jonathan.dru...@bugs.koha-community.org>) escribió: > Hello everybody, > > I have been listing some tasks I would like to work on during the next > development cycle. > I suggest a give and take approach. Help me on one or more of those > topics and I will help you as I can on whichever topic(s) you decide. > Great! > 2. Remove item-level_itype > We have been discussing this one for a long time already, is it the > time to tackle it down? > See > - > https://lists.koha-community.org/pipermail/koha-devel/2015-December/042114.html > - Bug 10385 - item-level_itypes checks need to be refactored > - Bug 29106 - Can we get rid of Koha::Item->effective_itemtype > I'm in! > 3. Merge biblio and biblioitem > Self-explanatory, merge the 2 tables to remove the unneeded 1-1 > relation between them > I'm in! > 4. Improve action logs > We have had several changes and reports in this area lately. We could > improve the way we log changes for easy tracking and comparaison. > See > - Bug 28714 - Bib record change tracking action log > - Bug 29451 - Merging records and authorities - log details for the > delete action so it could be recreated > - Bug 28692 - Reduce DB action_log table size > > I think we should add 2 new columns to log before and after the object > is updated, serialized in JSON. We could then generate the diff on > display. > ^^ this goes against the target goal for 28692. We should actually store diffs! > 5. Patron searches (holds and checkouts) > Those two patron searches do not use the same code as the other patron > searches. > We should uniformize them. > - Bug 29136 - Patron search on request.pl has performance and display > issues > - comment 37 of Bug 15812 - Checkout search with too many results > (single character search) causes poor performance or timeout > There is also bug 29125 (Use Koha::Patron object in > C4:Utils::DataTables::Members.pm) that is removing the SQL query to > use Koha::Patrons. > I'm happy to help. I suggest we explore using the API, that has pretty efficient queries (it automatically prefetches related objects, etc). > 5. Async ES indexation > Now that we have the task queue we should use it to index the records > and don't index them in a synchronous way. > Bug 27344 - Implement Elastic's update_index_background using > Koha::BackgroundJob > If we don't want to use the task queue for that purpose we should > provide another solution. > To be discussed and implemented (or validate and test the patches that > are already on bug 27344) > We should move both ES and Zebra indexing to the task_queue. I'm in! > 8. Move C4 and Koha to lib > We discussed that earlier and I even attached patches to bug 28589. I > don't think it's top priority but I can dedicate some hours if some of > you think it is a move we must do now. > We could go crazy and put all the intranet stuffs together as well :-D > And also, what's on your list for 22.05? > We need help with the ongoing discussion on https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29523 and friends. We need a performant solution and consensus on the approach, as it will impact how the API is/can be used. I would like to see the holds table merge pushed early and help is needed there. I want to move more pages into using the API, especially those using DataTables. Best regards -- Tomás Cohen Arazi Theke Solutions (http://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] My dev list for 22.05
Hello, Le 03/12/2021 à 12:03, Arthur a écrit : Friday's stone in the pond :) Were you thinking like what is done today for MARC / UNIMARC / NORMAC, choosing upon installation and then using one model? nope Or more as "mixing different data-models in one Koha"? yes -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries ___ Koha-devel mailing list Koha-devel@lists.koha-community.org 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] My dev list for 22.05
Friday's stone in the pond :) Were you thinking like what is done today for MARC / UNIMARC / NORMAC, choosing upon installation and then using one model? Or more as "mixing different data-models in one Koha"? That would need a column for storing the data model ID for each record and somewhere to store each data-model definitions (linking to the forementionned id). This looks a bit like what we do for Bokeh. Since we import records from different systems, we store the relation between a record or item and it's system of origin. We also store a mapping configuration for each system Bokeh is connected to (be it several Koha of different configuration, several ILS, ILS + online ressources, whatever combination...). On 03/12/2021 11:00, Paul Poulain wrote: Hello all, Regarding this topic : why not also investigate the new data models that will replace MARC ? We store the data in original form (marcxml) and move to biblio/biblioitems a part of the data that is useful for basic operation (like getting the title and the author). We could import different data models with the same mechanism (RDA, DC, ...). The biblio_metadata.format and schema fields were created with this idea in mind. That would require an additional layer for transforming format/schema to internal Koha and many more things, it's a long term goal. Le 01/12/2021 à 12:55, Jonathan Druart a écrit : 3. Merge biblio and biblioitem Self-explanatory, merge the 2 tables to remove the unneeded 1-1 relation between them ___ 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] My dev list for 22.05
Hello all, Regarding this topic : why not also investigate the new data models that will replace MARC ? We store the data in original form (marcxml) and move to biblio/biblioitems a part of the data that is useful for basic operation (like getting the title and the author). We could import different data models with the same mechanism (RDA, DC, ...). The biblio_metadata.format and schema fields were created with this idea in mind. That would require an additional layer for transforming format/schema to internal Koha and many more things, it's a long term goal. Le 01/12/2021 à 12:55, Jonathan Druart a écrit : 3. Merge biblio and biblioitem Self-explanatory, merge the 2 tables to remove the unneeded 1-1 relation between them -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries ___ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
