Send Koha-devel mailing list submissions to
koha-devel@lists.koha-community.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
or, via email, send a message with subject or body 'help' to
koha-devel-request@lists.koha-community.org
You can reach the person managing the list at
koha-devel-owner@lists.koha-community.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Koha-devel digest..."
Today's Topics:
1. Re: My dev list for 22.05 (Arthur)
2. Re: My dev list for 22.05 (Paul Poulain)
3. Re: My dev list for 22.05 (Tomas Cohen Arazi)
4. Re: My dev list for 22.05 (Magnus Enger)
5. Re: My dev list for 22.05 (Owen Leonard)
6. Re: My dev list for 22.05 (Michael Hafen (TECH))
----------------------------------------------------------------------
Message: 1
Date: Fri, 3 Dec 2021 12:03:21 +0100
From: Arthur <arthur.suzuki@biblibre.com>
To: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] My dev list for 22.05
Message-ID: <97c4ccd8-2d96-a038-09ea-a67dab1cf58e@biblibre.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
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
>
------------------------------
Message: 2
Date: Fri, 3 Dec 2021 15:20:11 +0100
From: Paul Poulain <paul.poulain@biblibre.com>
To: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] My dev list for 22.05
Message-ID: <cf4b8f4a-963a-a60f-423f-4deb97a944cd@biblibre.com>
Content-Type: text/plain; charset=utf-8; format=flowed
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
------------------------------
Message: 3
Date: Fri, 3 Dec 2021 11:32:28 -0300
From: Tomas Cohen Arazi <tomascohen@gmail.com>
To: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Cc: koha-devel <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] My dev list for 22.05
Message-ID:
<CABZfb=WSWCCpXpfsk3-9eCYMZgfSLTquB4HUYWtFEt_8vEjiUg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20211203/e9014f13/attachment-0001.htm>
------------------------------
Message: 4
Date: Fri, 3 Dec 2021 15:46:56 +0100
From: Magnus Enger <magnus@libriotech.no>
To: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] My dev list for 22.05
Message-ID: <99e49387-9836-5501-e0d7-929830943f97@libriotech.no>
Content-Type: text/plain; charset=utf-8; format=flowed
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
------------------------------
Message: 5
Date: Fri, 3 Dec 2021 10:51:04 -0500
From: Owen Leonard <oleonard@myacpl.org>
To: koha-devel <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] My dev list for 22.05
Message-ID:
<CAO4qe2P=NO4vMHq4LsPXEPrv=AqmaWzHqVdc+zRORzdrEeF2cg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
> 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
------------------------------
Message: 6
Date: Fri, 3 Dec 2021 11:13:47 -0700
From: "Michael Hafen (TECH)" <michael.hafen@washk12.org>
Cc: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] My dev list for 22.05
Message-ID:
<CAAh7Udm01k+7=5Y12fVazNsD+gBGS03itPf0osPMCyZ-ZPk+yQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20211203/5b710454/attachment.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
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/
------------------------------
End of Koha-devel Digest, Vol 193, Issue 6
******************************************