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.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