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. 1. Add more sample data to misc4dev It can be sometimes painful to recreate some situations when using the data provided by misc4dev. I would like to extend the data set to make some patches easier to test out of the box. We could, for instance, have: - big records - records with many items - records and items with cover images - more acquisition data - etc? Just tell me what kind of data you miss on a regular basis and I will try to add them to misc4dev. If you have such records/data, send them to me for inclusion! 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.h... - Bug 10385 - item-level_itypes checks need to be refactored - Bug 29106 - Can we get rid of Koha::Item->effective_itemtype The work would consist in providing a plan to go ahead then provide a patch. 3. Merge biblio and biblioitem Self-explanatory, merge the 2 tables to remove the unneeded 1-1 relation between them 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. 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. 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) 6. mailman2discourse It seems that people are willing to move from our historical mailing list to something more modern like discourse. I would like to get back to this job, who is willing to help me? 7. Split and shrink git repo I've already done several iterations in this area and I would like to get back to it. However I need someone with good git knowledge to continue and focus on this. 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. 9. Improve our strings for translators See - Bug 29602 - We must be nicer with translators - Bug 20988 - [OMNIBUS] Internationalization: wrap all translatable text inside t() calls I had to spend some time in the PO when I was releasing 21.11, and really we are not nice with translators. The %s everywhere make things very hard to maintain, read and translate. We should help them, and even if a big move is needed it will be a win in the long term, for us (developers) and for them. There are some other topics I have in mind, but those ones need to be done in small teams as they are quite big. Let me know what you think and if you are willing to give me a hand! And also, what's on your list for 22.05? Cheers, Jonathan
Hey Jonathan, Thanks for reaching out. We recently did a phpBB to Discourse move that's been live about a week now, so I'm happy to share my recent knowledge and experience for the "mailman2discourse" task. Other than that, I'm not sure how much help I have to give. I have a small interest in "Move C4 and Koha to lib", also small interest in "Improve action logs" since I use them quite a bit (although usually from the koha-mysql CLI rather than the web UI). -- As for my work... I haven't compiled a real list yet but... - Improving authentication generally (especially modularity via 24539, maybe 28507) (will hopefully be sponsored) - holds enhancements 15565 and 15516 (will hopefully be sponsored) - Replacing CGI scripts with Mojolicious controllers (28325, 26791) (I doubt anyone would sponsor this, especially as core module like C4/Auth.pm and C4/Template.pm need refactoring to make this work 100% correctly, so very very unlikely to happen, which is a bit unfortunate.) I also have a use case where I want to send Koha biblio data elsewhere on create/update/delete, but Koha plugins won't be suitable. I've been thinking that it would be good to publish a message to a RabbitMQ topic on biblio create/update/delete. In fact, that could potentially replace the existing C4::Biblio::_after_biblio_action_hooks and Koha::Item::_after_item_action_hooks functions, and then the background_jobs_worker.pl or some other work could invoke the plugins. Currently, I'm planning to modify the C4::Biblio::_after_biblio_action_hooks and Koha::Item::_after_item_action_hooks functions to push those create/update/delete messages to RabbitMQ. I probably won't use the Koha::BackgroundJob system, since I want the integration to be loosely coupled - the custom worker will just listen to the RabbitMQ topic and that's all Koha core will have to know about it. That's probably all for now heh. 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 <koha-devel-bounces@lists.koha-community.org> On Behalf Of Jonathan Druart Sent: Wednesday, 1 December 2021 10:56 PM To: koha-devel <koha-devel@lists.koha-community.org> Subject: [Koha-devel] My dev list for 22.05 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. 1. Add more sample data to misc4dev It can be sometimes painful to recreate some situations when using the data provided by misc4dev. I would like to extend the data set to make some patches easier to test out of the box. We could, for instance, have: - big records - records with many items - records and items with cover images - more acquisition data - etc? Just tell me what kind of data you miss on a regular basis and I will try to add them to misc4dev. If you have such records/data, send them to me for inclusion! 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.h... - Bug 10385 - item-level_itypes checks need to be refactored - Bug 29106 - Can we get rid of Koha::Item->effective_itemtype The work would consist in providing a plan to go ahead then provide a patch. 3. Merge biblio and biblioitem Self-explanatory, merge the 2 tables to remove the unneeded 1-1 relation between them 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. 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. 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) 6. mailman2discourse It seems that people are willing to move from our historical mailing list to something more modern like discourse. I would like to get back to this job, who is willing to help me? 7. Split and shrink git repo I've already done several iterations in this area and I would like to get back to it. However I need someone with good git knowledge to continue and focus on this. 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. 9. Improve our strings for translators See - Bug 29602 - We must be nicer with translators - Bug 20988 - [OMNIBUS] Internationalization: wrap all translatable text inside t() calls I had to spend some time in the PO when I was releasing 21.11, and really we are not nice with translators. The %s everywhere make things very hard to maintain, read and translate. We should help them, and even if a big move is needed it will be a win in the long term, for us (developers) and for them. There are some other topics I have in mind, but those ones need to be done in small teams as they are quite big. Let me know what you think and if you are willing to give me a hand! And also, what's on your list for 22.05? Cheers, Jonathan _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
I also have a use case where I want to send Koha biblio data elsewhere on create/update/delete, but Koha plugins won't be suitable. I've been thinking that it would be good to publish a message to a RabbitMQ topic on biblio create/update/delete. In fact, that could potentially replace the existing C4::Biblio::_after_biblio_action_hooks and Koha::Item::_after_item_action_hooks functions, and then the background_jobs_worker.pl or some other work could invoke the plugins.
I am running plugins to do the same for some time already. They are pushing these crud actions to a message queue. Works fine for me. Could you tell what makes plugins not suitable for that task? Ook in het Rijksmuseum: Document Nederland 2021: Afstand. Henk Wildschut fotografeert corona xxx Please think before you print
That’s cool to hear, Marcel! Happy to share my thoughts. A couple reasons I don’t want to use plugins: 1. I don’t want to turn on Koha plugins for 100+ different Koha instances around the world. a. Overall, I think the Koha plugin system is insecure, and allows library staff too much control over the system. I typically keep it disabled with only a few exceptions. (I’ve opened a few bugs and provided a few patches for improving plugin security but they haven’t gone anywhere yet on Bugzilla.) b. I also wouldn’t want library staff to potentially meddle with the plugin I install. I think this plugin is really a system plugin rather than a user plugin. It should be invisible to library staff. 2. I’d be looking to install/upgrade plugin code on 100+ different Koha instances which presents a maintenance challenge a. While I think some vendors use Ansible to do this, I’m not currently satisfied with the CLI plugin tooling for install/upgrade/downgrade/uninstall. (I’ve done some work on this as well on Bugzilla but the work hasn’t progressed and it’s dropped down my priority list.) i. Using an Ansible push also isn’t an option in some security/operational contexts. In some contexts, you provide artifacts and leave deployment/operations up to a different team b. I rather install this “system plugin” 1 time on a server rather than X times. (I think this is something some other vendors have struggled with and worked around as well.) c. I’d need to change the instance creation process to install this plugin as well. (Not the end of the world but a bit annoying and introduces more room for errors.) That said, the hooks already exist, so I can see the appeal, and I can see how they’d work well for other people, especially with fewer Koha instances to manage. I suppose it mostly comes down to control, security, and maintenance/management. Also, other systems like Dspace and Fedora write out to message queues out of the box, and it makes it easy to add integrations to them without touching the core application at all. It would be great if Koha could do the same without needing a plugin. (If it were core functionality, we could use it for indexing as well and replace the “zebraqueue”.) 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 <koha-devel-bounces@lists.koha-community.org> On Behalf Of Marcel de Rooy Sent: Thursday, 2 December 2021 6:15 PM To: 'koha-devel' <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] [Changed topic] Action hooks
I also have a use case where I want to send Koha biblio data elsewhere on create/update/delete, but Koha plugins won't be suitable. I've been thinking that it would be good to publish a message to a RabbitMQ topic on biblio create/update/delete. In fact, that could potentially replace the existing C4::Biblio::_after_biblio_action_hooks and Koha::Item::_after_item_action_hooks functions, and then the background_jobs_worker.pl or some other work could invoke the plugins.
I am running plugins to do the same for some time already. They are pushing these crud actions to a message queue. Works fine for me. Could you tell what makes plugins not suitable for that task? <https://www.rijksmuseum.nl/nl/zien-en-doen/tentoonstellingen/vergeet-me-niet> Ook in het Rijksmuseum: <https://www.rijksmuseum.nl/nl/zien-en-doen/tentoonstellingen/henk-wildschut> Document Nederland 2021: Afstand. Henk Wildschut fotografeert corona <https://www.rijksmuseum.nl/nl/zien-en-doen?filter=familiemaand> <https://www.instagram.com/rijksmuseum/> x <https://www.facebook.com/rijksmuseum> x <https://www.linkedin.com/company/rijksmuseum/> x <https://twitter.com/rijksmuseum> Please think before you print
I’ve been thinking about this more today, and I think that I’m coming around to the plugin idea. I still think it would be a good idea to have an event-driven messaging system, but it seems to me that adding that system will take a lot more work/discussion/thinking/experimenting than just improving plugin security and plugin tooling… so I might return to looking at some of the following: Bug 28499 - Add support for no-UI / administrative plugins https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28499 Bug 25672 - Administrators should be able to disable client-side plugin upload https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25672 Bug 25370 - Create allowlist of plugins allowed to be installed by Web UI https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25370 Bug 24632 - Plugins should support simple signing for security/verifiability https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24632 Bug 25671 - Install 1 Koha plugin for X Koha instances using the CLI https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25671 Bug 28498 - Add CLI counterpart for plugin actions https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28498 At the moment, I’m more concerned with security than logistics I think. I think the most feasible option with the least amount of work is probably going to be Bug 25370. I’ll default to allowing all plugins to be loaded, and then locally I’ll just make sure that all instances have a restricted list. That should make everyone happy… 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 <koha-devel-bounces@lists.koha-community.org> On Behalf Of dcook@prosentient.com.au Sent: Friday, 3 December 2021 9:59 AM To: 'Marcel de Rooy' <M.de.Rooy@rijksmuseum.nl>; 'koha-devel' <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] [Changed topic] Action hooks That’s cool to hear, Marcel! Happy to share my thoughts. A couple reasons I don’t want to use plugins: 1. I don’t want to turn on Koha plugins for 100+ different Koha instances around the world. a. Overall, I think the Koha plugin system is insecure, and allows library staff too much control over the system. I typically keep it disabled with only a few exceptions. (I’ve opened a few bugs and provided a few patches for improving plugin security but they haven’t gone anywhere yet on Bugzilla.) b. I also wouldn’t want library staff to potentially meddle with the plugin I install. I think this plugin is really a system plugin rather than a user plugin. It should be invisible to library staff. 2. I’d be looking to install/upgrade plugin code on 100+ different Koha instances which presents a maintenance challenge a. While I think some vendors use Ansible to do this, I’m not currently satisfied with the CLI plugin tooling for install/upgrade/downgrade/uninstall. (I’ve done some work on this as well on Bugzilla but the work hasn’t progressed and it’s dropped down my priority list.) i. Using an Ansible push also isn’t an option in some security/operational contexts. In some contexts, you provide artifacts and leave deployment/operations up to a different team b. I rather install this “system plugin” 1 time on a server rather than X times. (I think this is something some other vendors have struggled with and worked around as well.) c. I’d need to change the instance creation process to install this plugin as well. (Not the end of the world but a bit annoying and introduces more room for errors.) That said, the hooks already exist, so I can see the appeal, and I can see how they’d work well for other people, especially with fewer Koha instances to manage. I suppose it mostly comes down to control, security, and maintenance/management. Also, other systems like Dspace and Fedora write out to message queues out of the box, and it makes it easy to add integrations to them without touching the core application at all. It would be great if Koha could do the same without needing a plugin. (If it were core functionality, we could use it for indexing as well and replace the “zebraqueue”.) 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 <koha-devel-bounces@lists.koha-community.org <mailto:koha-devel-bounces@lists.koha-community.org> > On Behalf Of Marcel de Rooy Sent: Thursday, 2 December 2021 6:15 PM To: 'koha-devel' <koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> > Subject: Re: [Koha-devel] [Changed topic] Action hooks
I also have a use case where I want to send Koha biblio data elsewhere on create/update/delete, but Koha plugins won't be suitable. I've been thinking that it would be good to publish a message to a RabbitMQ topic on biblio create/update/delete. In fact, that could potentially replace the existing C4::Biblio::_after_biblio_action_hooks and Koha::Item::_after_item_action_hooks functions, and then the background_jobs_worker.pl or some other work could invoke the plugins.
I am running plugins to do the same for some time already. They are pushing these crud actions to a message queue. Works fine for me. Could you tell what makes plugins not suitable for that task? <https://www.rijksmuseum.nl/nl/zien-en-doen/tentoonstellingen/vergeet-me-niet> Ook in het Rijksmuseum: <https://www.rijksmuseum.nl/nl/zien-en-doen/tentoonstellingen/henk-wildschut> Document Nederland 2021: Afstand. Henk Wildschut fotografeert corona <https://www.rijksmuseum.nl/nl/zien-en-doen?filter=familiemaand> <https://www.instagram.com/rijksmuseum/> x <https://www.facebook.com/rijksmuseum> x <https://www.linkedin.com/company/rijksmuseum/> x <https://twitter.com/rijksmuseum> Please think before you print
A first reply on the points you mention. I would like to add a few on my second reply ;)
2. Remove item-level_itype I agree. Happy to support that one.
3. Merge biblio and biblioitem I understand that you want that. But just feeling that it might be harder to swallow..
The other points are surely interesting. Op wo 1 dec. 2021 om 16:24 schreef Jonathan Druart < jonathan.druart@bugs.koha-community.org>:
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.
1. Add more sample data to misc4dev It can be sometimes painful to recreate some situations when using the data provided by misc4dev. I would like to extend the data set to make some patches easier to test out of the box. We could, for instance, have: - big records - records with many items - records and items with cover images - more acquisition data - etc?
Just tell me what kind of data you miss on a regular basis and I will try to add them to misc4dev. If you have such records/data, send them to me for inclusion!
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.h... - Bug 10385 - item-level_itypes checks need to be refactored - Bug 29106 - Can we get rid of Koha::Item->effective_itemtype
The work would consist in providing a plan to go ahead then provide a patch.
3. Merge biblio and biblioitem Self-explanatory, merge the 2 tables to remove the unneeded 1-1 relation between them
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.
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.
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)
6. mailman2discourse It seems that people are willing to move from our historical mailing list to something more modern like discourse. I would like to get back to this job, who is willing to help me?
7. Split and shrink git repo I've already done several iterations in this area and I would like to get back to it. However I need someone with good git knowledge to continue and focus on this.
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.
9. Improve our strings for translators See - Bug 29602 - We must be nicer with translators - Bug 20988 - [OMNIBUS] Internationalization: wrap all translatable text inside t() calls I had to spend some time in the PO when I was releasing 21.11, and really we are not nice with translators. The %s everywhere make things very hard to maintain, read and translate. We should help them, and even if a big move is needed it will be a win in the long term, for us (developers) and for them.
There are some other topics I have in mind, but those ones need to be done in small teams as they are quite big.
Let me know what you think and if you are willing to give me a hand!
And also, what's on your list for 22.05?
Cheers, Jonathan _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
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
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
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
If I may throw another stone in this pond... ;) I think it would be interesting to flip the relationship between the biblio/biblioitems/items tables and the marcxml data. Using the biblio_metadata table we could store every piece of information necessary to generate marcxml from there and the biblio/biblioitems/items tables. This would make those tables authoritative. We could even go as far as not storing the marcxml, but generating it on the fly as necessary. We could take this a step farther and use the marc_*_structure tables to represent which ever model we want to support by adding a format indicator; for example specifying a set of tag/subfield rows as being for UNIMARC, and then any data coming in to or going out from Koha in that format would go from the biblio/biblioitems/items/biblio_metadata through the marc_*_structure (koha to marc mappings) to UNIMARC, or visa-versa. The biblio and item edit screens would likewise use the biblio/items/biblio_metadata tables instead of the marcxml data. This would make imports, exports, and search engine updates more complicated, as the MARC format data would have to be generated on the fly. The trade off is that everything else in Koha could become less complicated as it would all reference the biblio/items/biblio_metadata tables directly without having to decode / encode MARC in the system format. The difference in complexity is small, but it is there. In addition, all the record data would be available directly through sql without having to go through extracting data from marcxml for some things. Admittedly, this is a very extreme idea compared to how Koha works now. But it bugs me a little that we have two copies of each record ( in the biblio/items tables and in the marcxml ), and have to take care to make sure they are kept up to date with each other. Anyway, there's an idea, since we're talking about future developments and supporting data formats besides MARC. On Fri, Dec 3, 2021 at 7:20 AM Paul Poulain <paul.poulain@biblibre.com> wrote:
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/
-- Michael Hafen Washington County School District Technology Department Systems Analyst
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
El mié, 1 dic 2021 a las 12:24, Jonathan Druart (< jonathan.druart@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.h... - 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
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
Currently I am working on moving the OverDrive code into a plugin to update for changes in their API, and to make it easier to adapt in the future I hope to continue working this cycle on performance in searching and loading pages throughout Koha ByWater at large is going to be working on improving the Koha2Koha ILL plugin, developing a more generic OAuth connector, and other sponsored devs Generally too, we have a number of devs in the community we would like to complete and get into Koha. We're happy to help where we can, please give a ping :-) On Fri, Dec 3, 2021 at 10:51 AM Owen Leonard <oleonard@myacpl.org> wrote:
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/
-- Nick Clemens ByWater Solutions bywatersolutions.com Phone: (888) 900-8944 Pronouns: (he/him/his) Timezone: Eastern Follow us: <https://www.facebook.com/ByWaterSolutions/> <https://www.instagram.com/bywatersolutions/> <https://www.youtube.com/user/bywatersolutions> <https://twitter.com/ByWaterSolution>
Hey Nick, What do you mean by a more generic OAuth connector? I’ve already done a lot of authentication work locally and hopefully will do more in the community in the time to come, so happy to collaborate more on that. (I find the hardest part of authentication work is not the code, but rather getting community support for moving developments along, so let’s pair up and get some AuthN work done!) 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 <koha-devel-bounces@lists.koha-community.org> On Behalf Of Nick Clemens Sent: Wednesday, 8 December 2021 11:37 PM To: Owen Leonard <oleonard@myacpl.org> Cc: koha-devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] My dev list for 22.05 Currently I am working on moving the OverDrive code into a plugin to update for changes in their API, and to make it easier to adapt in the future I hope to continue working this cycle on performance in searching and loading pages throughout Koha ByWater at large is going to be working on improving the Koha2Koha ILL plugin, developing a more generic OAuth connector, and other sponsored devs Generally too, we have a number of devs in the community we would like to complete and get into Koha. We're happy to help where we can, please give a ping :-) On Fri, Dec 3, 2021 at 10:51 AM Owen Leonard <oleonard@myacpl.org <mailto:oleonard@myacpl.org> > wrote:
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 <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/ -- Nick Clemens ByWater Solutions bywatersolutions.com <http://bywatersolutions.com> Phone: (888) 900-8944 Pronouns: (he/him/his) Timezone: Eastern <https://docs.google.com/uc?export=download&id=1eLlHaKRZxg0CP6nlW7rG0J4qdtoIuoNr&revid=0B0ga69kSs543QWlEa3V4aGI4dFlXMlVQd0ZEbVY5dFBXQUk0PQ> Follow us: <https://www.facebook.com/ByWaterSolutions/> <https://www.instagram.com/bywatersolutions/> <https://www.youtube.com/user/bywatersolutions> <https://twitter.com/ByWaterSolution>
I'm sorry, I've been struggling to find a moment to reply to this one. I'm currently working through 'Bundles'. 'Bookings' and a 'Logistics Plugin' for a new customer and they've taking up a lot of headspace and time... I'd love to get the Bundles code into the community this cycle, and with any luck, I'll have enough of the Bookings piece to submit early in the new year too. As for the rest of the cycle, 1. misc4dev, I don't really have a boat in the race here.. I don't personally use it directly in any way and I'm not close enough to it to know what knock on effects it would have to help my workflows. 2. Remove item-level_itype, I'm interested to see where this goes and can help test. 3. Mergeing biblio and biblioitem, I'd love to see this happen.. I always find the two tables confusing.. I can help test and QA. 4. I agree with Tomas, I don't think we should be storing whole dumps, especially not twice. I would like to see a diff approach using one of the standard libraries out there.. as for what one, that's a harder call. 5(1). Patron searches: My recent devs are all moving towards using the API's where possible and I try to create re-usable client side components.. it's not easy with our current workflows. I'd need to look at your proposals in more depth again, but last I looked I felt we were opposed in our thoughts here? 5(2). Async indexing, yup.. I'm in on this one.. and have been for a while.. just need to schedule some time to look at what the current state of affairs is. 6. Looking forward to seeing the results, but not an area I have any expertise in.. so will happily defer to others on this one. 7. As keen as I am to see something here, whilst things continue to work I have other higher priorities. It's taken so long to get to this stage I've forgotten the background reasons for doing it :( 8. I like the idea here.. and agree it would be good to move intranet scripts into their own directory too (there's a security bug that started this long ago) 9. Translation is important and I do try to help where I can.. but as a native English speaker and one whose customers are majoritorily also native English I struggle to set enough time aside to help on these efforts. However.. I really would like to see the AV translations bugs move forward.. I find myself blocked on many things because we don't have a decent way to translate data that's in the database. 10. Add a way to prevent embedding objects that should not be allowed - This one is important to me, we need to make sure our API is secure, suitable and performant so we can push to using it more. 11. I'd love to see Koha's permissions working a little more clearly as a first step towards giving us OAuth scopes and a cleaner API authentication/authorization process. 12. I aim to continue to support the documentation team to help improve efficiencies there. *Martin Renvoize, MPhys (Hons)* <https://www.ptfs-europe.com> Head of Development and Community Engagement *Phone:* +44 (0) 1483 378728 *Mobile:* +44 (0) 7725 985 636 *Email:* martin.renvoize@ptfs-europe.com www.ptfs-europe.com *Sign up for our newsletters here <http://eepurl.com/dPjjkn> or by scanning the QR code* Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info@ptfs-europe.com On Wed, 8 Dec 2021 at 22:08, <dcook@prosentient.com.au> wrote:
Hey Nick,
What do you mean by a more generic OAuth connector?
I’ve already done a lot of authentication work locally and hopefully will do more in the community in the time to come, so happy to collaborate more on that. (I find the hardest part of authentication work is not the code, but rather getting community support for moving developments along, so let’s pair up and get some AuthN work done!)
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 <koha-devel-bounces@lists.koha-community.org> *On Behalf Of *Nick Clemens *Sent:* Wednesday, 8 December 2021 11:37 PM *To:* Owen Leonard <oleonard@myacpl.org> *Cc:* koha-devel <koha-devel@lists.koha-community.org> *Subject:* Re: [Koha-devel] My dev list for 22.05
Currently I am working on moving the OverDrive code into a plugin to update for changes in their API, and to make it easier to adapt in the future
I hope to continue working this cycle on performance in searching and loading pages throughout Koha
ByWater at large is going to be working on improving the Koha2Koha ILL plugin, developing a more generic OAuth connector, and other sponsored devs
Generally too, we have a number of devs in the community we would like to complete and get into Koha.
We're happy to help where we can, please give a ping :-)
On Fri, Dec 3, 2021 at 10:51 AM Owen Leonard <oleonard@myacpl.org> wrote:
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/
--
Nick Clemens
ByWater Solutions
bywatersolutions.com
Phone: (888) 900-8944
Pronouns: (he/him/his) Timezone: Eastern
Follow us:
<https://www.facebook.com/ByWaterSolutions/> <https://www.instagram.com/bywatersolutions/> <https://www.youtube.com/user/bywatersolutions> <https://twitter.com/ByWaterSolution> _______________________________________________ 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/
1. misc4dev, I don't really have a boat in the race here.. I don't personally use it directly in any way and I'm not close enough to it to know what knock on effects it would have to help my workflows.
It's used by koha-testing-docker, so you are using misc4dev daily. For instance the items/biblios/authorities records you see when using ktd are coming from this repo.
4. I agree with Tomas, I don't think we should be storing whole dumps, especially not twice. I would like to see a diff approach using one of the standard libraries out there.. as for what one, that's a harder call.
What if we decide to change the libraries later? We could still have 2 new (before/after) columns but with the diff only? before { opac_note => 'a note' } after { opac_note => 'modified note' }
5(1). Patron searches: My recent devs are all moving towards using the API's where possible and I try to create re-usable client side components.. it's not easy with our current workflows. I'd need to look at your proposals in more depth again, but last I looked I felt we were opposed in our thoughts here?
There are several things. The first one is making them all the current system (15812 and 29136). Then making them all use the REST API. I am sure you don't disagree with that :) What did you have in mind?
5(2). Async indexing, yup.. I'm in on this one.. and have been for a while.. just need to schedule some time to look at what the current state of affairs is.
Oops, there were 2 5's! It's ready for testing and QA actually, I updated the status accordingly.
7. As keen as I am to see something here, whilst things continue to work I have other higher priorities. It's taken so long to get to this stage I've forgotten the background reasons for doing it :(
Repo size, from 2.4G (or 4G? I lost track) to ~200M
8. I like the idea here.. and agree it would be good to move intranet scripts into their own directory too (there's a security bug that started this long ago) 9. Translation is important and I do try to help where I can.. but as a native English speaker and one whose customers are majoritorily also native English I struggle to set enough time aside to help on these efforts. However.. I really would like to see the AV translations bugs move forward.. I find myself blocked on many things because we don't have a decent way to translate data that's in the database. 10. Add a way to prevent embedding objects that should not be allowed - This one is important to me, we need to make sure our API is secure, suitable and performant so we can push to using it more. 11. I'd love to see Koha's permissions working a little more clearly as a first step towards giving us OAuth scopes and a cleaner API authentication/authorization process. 12. I aim to continue to support the documentation team to help improve efficiencies there.
Thanks for your reply!
*Martin Renvoize, MPhys (Hons)*
Head of Development and Community Engagement
*Phone:* +44 (0) 1483 378728
*Mobile:* +44 (0) 7725 985 636
*Email:* martin.renvoize@ptfs-europe.com
www.ptfs-europe.com
*Sign up for our newsletters here <http://eepurl.com/dPjjkn> or by scanning the QR code*
Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30
The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info@ptfs-europe.com
On Wed, 8 Dec 2021 at 22:08, <dcook@prosentient.com.au> wrote:
Hey Nick,
What do you mean by a more generic OAuth connector?
I’ve already done a lot of authentication work locally and hopefully will do more in the community in the time to come, so happy to collaborate more on that. (I find the hardest part of authentication work is not the code, but rather getting community support for moving developments along, so let’s pair up and get some AuthN work done!)
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 <koha-devel-bounces@lists.koha-community.org> *On Behalf Of *Nick Clemens *Sent:* Wednesday, 8 December 2021 11:37 PM *To:* Owen Leonard <oleonard@myacpl.org> *Cc:* koha-devel <koha-devel@lists.koha-community.org> *Subject:* Re: [Koha-devel] My dev list for 22.05
Currently I am working on moving the OverDrive code into a plugin to update for changes in their API, and to make it easier to adapt in the future
I hope to continue working this cycle on performance in searching and loading pages throughout Koha
ByWater at large is going to be working on improving the Koha2Koha ILL plugin, developing a more generic OAuth connector, and other sponsored devs
Generally too, we have a number of devs in the community we would like to complete and get into Koha.
We're happy to help where we can, please give a ping :-)
On Fri, Dec 3, 2021 at 10:51 AM Owen Leonard <oleonard@myacpl.org> wrote:
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/
--
Nick Clemens
ByWater Solutions
bywatersolutions.com
Phone: (888) 900-8944
Pronouns: (he/him/his) Timezone: Eastern
Follow us:
<https://www.facebook.com/ByWaterSolutions/> <https://www.instagram.com/bywatersolutions/> <https://www.youtube.com/user/bywatersolutions> <https://twitter.com/ByWaterSolution> _______________________________________________ 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/
Sorry for the delay. I already responded to your points. But here are a few points from me. Note that a list like this is just like a photograph. I need help on the following bugs (signoffs): Without advertizing them, some even very small patches unfortunately may be in the NSO queue for months. Or totally ignored; i regularly remove code after 3 or 4 months. 28962 Koha Command- m.de.rooy@rijksmuseum.nl Need --- nor Unverified self registrations should be removed shortly 2021-10-07 28943 Koha Command- m.de.rooy@rijksmuseum.nl Need --- nor Lower the risk of accidental patron deletion by cleanup_database.pl 2021-10-11 29554 Koha Acquisit m.de.rooy@rijksmuseum.nl Need --- min neworderempty.pl may create records with biblioitems.itemtype NULL 2021-11-22 29542 Koha sec Koha m.de.rooy@rijksmuseum.nl Need --- nor User with 'catalogue' permission can view everybody's (private) virtualshelves 2021-12-03 29592 Koha Catalogi m.de.rooy@rijksmuseum.nl Need --- min Imported records should not be completed with defaultvalues 2021-12-06 29658 Koha Acquisit m.de.rooy@rijksmuseum.nl Need --- min Crash on cancelling cancelled order 2021-12-08 29673 Koha Installa m.de.rooy@rijksmuseum.nl Need --- enh Allow an English sql localization script 2021-12-10 29336 Koha Architec m.de.rooy@rijksmuseum.nl Need --- nor Some authorised_value FKs are too short 09:09:21 29314 Koha Architec m.de.rooy@rijksmuseum.nl Need --- enh Move some OpenURL code to Koha::Biblio 09:21:22 I want to submit some patches for at least these reports: Bug 29412 - Fix uncertain years before 1000 AD in copyrightdate => See also 19206 Koha Architec koha-bugs@lists.koha-commun... NEW --- How should we sort 19xx when order is pubdate? Bug 29144 - Make branches.opac_info suitable for multi language use => NOTE: The current status of news/HTML customizations is not very stable! It needs more attention. => See also: 29190 Koha OPAC koha-bugs@lists.koha-commun... NEW --- Allow cached news pages by code from opac-main 29687 Koha Architec m.de.rooy@rijksmuseum.nl ASSI --- Get rid of a few OPAC warnings Mon 13:29 And perhaps: 20570 Koha Command- m.de.rooy@rijksmuseum.nl ASSI --- Add script to complete scanned article requests 2021-07-13 28990 Koha System A koha-bugs@lists.koha-commun... NEW --- Allow changes for a configurable subset of systempreferences by superlibrarian only 2021-09-14 And a few reports from other people: Bug 19532 Recalls for Koha Bug 2237 / Bug 29480 Add email address as a method for generating the userid Furthermore I want to mention patches for Two Factor Authentication. We are investigating possiblities to sponsor development on that front. And also I wrote two security patches recently. Not listing them here. Look at Bugzilla for the things I forgot 🙂 Marcel ________________________________ Van: Koha-devel <koha-devel-bounces@lists.koha-community.org> namens Jonathan Druart <jonathan.druart@bugs.koha-community.org> Verzonden: woensdag 1 december 2021 12:55 Aan: koha-devel <koha-devel@lists.koha-community.org> Onderwerp: [Koha-devel] My dev list for 22.05 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. 1. Add more sample data to misc4dev It can be sometimes painful to recreate some situations when using the data provided by misc4dev. I would like to extend the data set to make some patches easier to test out of the box. We could, for instance, have: - big records - records with many items - records and items with cover images - more acquisition data - etc? Just tell me what kind of data you miss on a regular basis and I will try to add them to misc4dev. If you have such records/data, send them to me for inclusion! 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.koha... - Bug 10385 - item-level_itypes checks need to be refactored - Bug 29106 - Can we get rid of Koha::Item->effective_itemtype The work would consist in providing a plan to go ahead then provide a patch. 3. Merge biblio and biblioitem Self-explanatory, merge the 2 tables to remove the unneeded 1-1 relation between them 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. 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. 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) 6. mailman2discourse It seems that people are willing to move from our historical mailing list to something more modern like discourse. I would like to get back to this job, who is willing to help me? 7. Split and shrink git repo I've already done several iterations in this area and I would like to get back to it. However I need someone with good git knowledge to continue and focus on this. 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. 9. Improve our strings for translators See - Bug 29602 - We must be nicer with translators - Bug 20988 - [OMNIBUS] Internationalization: wrap all translatable text inside t() calls I had to spend some time in the PO when I was releasing 21.11, and really we are not nice with translators. The %s everywhere make things very hard to maintain, read and translate. We should help them, and even if a big move is needed it will be a win in the long term, for us (developers) and for them. There are some other topics I have in mind, but those ones need to be done in small teams as they are quite big. Let me know what you think and if you are willing to give me a hand! And also, what's on your list for 22.05? Cheers, Jonathan _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.koha... website : https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.koha-c... git : https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.koha-c... bugs : https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.koha-...
participants (12)
-
Arthur -
dcook＠prosentient.com.au -
Jonathan Druart -
Magnus Enger -
Marcel de Rooy -
Marcel de Rooy -
Michael Hafen (TECH) -
Nick Clemens -
Owen Leonard -
Paul Poulain -
Renvoize, Martin -
Tomas Cohen Arazi