[Koha-devel] Get rid of item-level_itype?

[Paul A]

Apologies for top-posting. Thanks Jonathan and Katrin for what is obviously 
a close look into "item types."

Maybe I've missed some detail, so, while I am a great believer in tidying 
up code, could I ask what the functional gains are?

I've looked at the Wiki page mentioned below, and it seems as though the 
French and USA libraries difference was "abandoned" (2010? v.3.0 ==> 3.2) 
but implies that it was no longer relevant (problem fixed?)

Katrin reinforces some points that "jump out" for me:

         - updating MySQL databases at structural level can have widespread 
repercussions.

         - these repercussions impact the (hundreds? of) Perl scripts (and 
possibly .css, .js, .tt, etc) files in the various Koha distributions -- 
testing and QA will be challenging at the very least.

         - (as a consequence?) any institution using a "pre-MySQL update" 
version of Koha as either backup or production server, will need additional 
scripts to ensure dump/restore procedures (we certainly cannot take the 
risk of updating backup and production simultaneously without at least one 
bullet-proof "sandbox.") Add to this Katrin's well-taken point on complete 
Zebra re-indexing.

         - there are also potential repercussions in any user customization 
-- MySQL "reports", .css and .js which the Koha community has encouraged, 
possibly .inc, .xml, .xsl and .tt which we have probably occasionally 
encouraged -- and possibly elsewhere. A quick look at our internal 
"reports" shows that we have at least nineteen that use various flavours of 
item types.)

"Return on investment" (ROI) is perhaps an over-utilized catchphrase, but 
can we please define the "production gains" (even if code beauty suffers a 
tad)?

Many thanks and best (seasonal) regards,
Paul

P.S. Philosophically, would it be possible to consider a "major version" 
change. Some fundamental deltas (ElasticSearch and others, as well as code 
cleaning -- C4auth springs to mind) could be incorporated into Koha 4.xx 
and backwards compatibility would not necessarily be an absolute assumption.)


At 08:24 AM 12/23/2015 +0100, Katrin Fischer wrote:
>Hi Jonathan,
>
>thx for looking into this!
>
>Am 17.12.2015 um 17:41 schrieb Jonathan Druart:
> > Update DB migration:
> > 1/ add column biblio.biblio_type
> > 2/ update biblio.biblio_type with biblioitems.itemtype
> > 3/ rename items.itype with items.item_type
> > 4/ set items.item_type = biblio.biblio_type if items.item_type is not
> > defined (or if item_level_itypes is not set?)
> > 5/ rename deleteditems.itype with items.item_type, and don't update it 
> (right?)
>Hm, I think I'd update it for consistency and easier use for reporting.
> > 6/ drop column biblioitems.itemtype
> > 7/ rename course_items.itype with course_items.item_type (to be consistent)
>
>I am not sure about renaming the columns. Some thoughts:
>
>Both the itemtype on items and on biblio level will still refer to an
>entry in the itemtypes table. So if we rename, maybe we should reflect
>the connection somehow.
>
>It also looks like we are using 'itemtype' over 'item_type' in a lot of
>other tables: statistics, branchrules, default_branch_item_rules,
>issuingrules, suggestions...
>
>I think changing items.itype to items.itemtype would make sense to me.
>For record level... I am not sure about moving from biblioitems to
>biblio, it will mean that a lot of the reports will be broken and we
>probably can't fix them easily with a script.
>
> > Then we will have to replace the notices ^items.itype^items.item_type^
> > and ^biblioitems.itemtype^biblio.biblio_type^ should solve the
> > problem.
>
>We should think about doing something similar to the custom SQL reports
>- I think there are probably a lot in all the databases that use the
>itemtypes in some way.
>
> > Looking at the code, I have found some places where I am not sure how
> > to fix the display:
> > 1/ For instance on the detail page of a biblio, or when a user place a
> > hold, the item type is display either *on top* of the items list, or
> > *in* a specific column of the table.
> > Which makes sense. If we remove the pref, we have 3 choices:
> >   a. always display the item type in the table
> >   b. display the item type on top only if all item types are identical
> > at the biblio type (will require some additional loops)
> >   c. display both and set a css class: the library will be able to
> > hide the one it wants
> >   d. the answer d
>
>Hm, for me it's either a or c. Or maybe d?  ;)
>
> > 2/ The change will require a complete reindexation of zebra: the index
> > will be renamed  (itype => item_type, mc-itype => mc-item_type,
> > itemtype => biblio_type, mc-itemtype => mc-biblio_type).
> > Is it acceptable?
>
>Hm, I am not sure how commonly people reindex after updating. Generally
>I think it's a good idea, but I am not sure we have this documented
>well. Could we avoid renaming maybe and use aliases so the old index
>names still work?
>
> > I think I can  produce a patch in 2 days of work (which is nothing
> > compared to the number of days Koha developpers have lost to
> > understand how this code works...), but it will require a lot of deep
> > testing.
> > It will really hard to provide tests for this change since it impacts
> > a lot of file, but I will write some for the most common subroutines.
> >
> > I would like some people engaged in the signoff process, not to let
> > the patches in the signoff queue too long.
> >
> > Cheers,
> > Jonathan
> >
> > 2015-12-11 12:04 GMT+00:00 Jonathan Druart
> > <jonathan.druart at bugs.koha-community.org>:
> >> Hi devs,
> >>
> >> Friday is a good day for this kind of questions, fasten your seat belt
> >> for a time travel.
> >>
> >> As many of you know, the item type is not correctly managed all around
> >> the different Koha modules. Sometimes it's, sometimes it's not.
> >> The main issue is that we deal with it at too many places and the code
> >> is not clean/centralised at all.
> >>
> >> So I have searched for previous discussions on this subject and I have
> >> found this "Abandoned RFC" on the wiki :
> >> 
> http://wiki.koha-community.org/wiki/Mandate_item-level_circulation_rules_RFC
> >> filled from this koha-devel thread
> >> 
> http://lists.koha-community.org/pipermail/koha-devel/2008-October/031144.html
> >>
> >> The questions are:
> >> 1/ Is this still valid?
> >> 2/ Is there something missing in the different steps described?
> >> 3/ Does someone have some other suggestions to do?
> >>
> >> I would be happy to provide this change but first I would like to get
> >> confirmation about it and get people involved in signoffing/QAing the
> >> possible patch set.
> >>
> >> Cheers,
> >> Jonathan