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.htm... 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
If you mean the syspref, I agree we could remove it. Regarding the itemtype "calculation", we shoudl just use Koha::Item->effective_itemtype all over the place, well, and Koha::Item(s) heh. 2015-12-11 9:04 GMT-03:00 Jonathan Druart < jonathan.druart@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.htm...
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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F
+1 for removing complexity Marc Véron Am 11.12.2015 um 13:04 schrieb Jonathan Druart:
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.htm...
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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
I'm curious how this fits in with the bugs Koha has for limiting the number of holds a patron can place--something Koha still fails to do properly. Hold limits ignored for record level holds with item level itemtypes http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12632 It would be useful to get Kyle's opinion since he's probably the person with the best understanding of Koha holds these days. -- Owen
The rfc made sense to me; I think that it is the right approach. Here are a few things to consider: 1/ There are a *lot* of reports written that use items.itype. I don't like the fact that this isn't called items.itemtype, but unless we have a seamless and foolproof transition, this will cause massive amounts of pain. This includes the sql report library on the wiki. 2/ I think that there should be a method of locking the default itemtype to NULL so that it is not accidentally set by libraries who currently use item level itemtypes... Having that get set accidentally would be a pain to trouble-shoot. 3/ There are libraries who use item level itemtypes who currently have data in the biblioitems.itemtype... Just due to the fact that we haven't previously made it impossible, I'm sure that it's happened... So we need to delete those if they're there. These are all the reasonable caveats that I can think of. I had a couple of unreasonable ones as well... see the obligatory https://xkcd.com/1172/ On Dec 11, 2015 7:05 AM, "Jonathan Druart" < jonathan.druart@bugs.koha-community.org> wrote:
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.htm...
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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
I am in favour or removing the item-level_itype system preference and for centralizing all itemtype related code. But I think we have still have a need/use for the biblio level itemtype apart from it setting the default for the items level. I know there was some work done to use it for holds related code. And also patches like document delivery (bug 14610) depend on it to allow requests for records without items. Katrin Am 12.12.2015 um 14:46 schrieb Barton Chittenden:
The rfc made sense to me; I think that it is the right approach. Here are a few things to consider:
1/ There are a *lot* of reports written that use items.itype. I don't like the fact that this isn't called items.itemtype, but unless we have a seamless and foolproof transition, this will cause massive amounts of pain. This includes the sql report library on the wiki.
2/ I think that there should be a method of locking the default itemtype to NULL so that it is not accidentally set by libraries who currently use item level itemtypes... Having that get set accidentally would be a pain to trouble-shoot.
3/ There are libraries who use item level itemtypes who currently have data in the biblioitems.itemtype... Just due to the fact that we haven't previously made it impossible, I'm sure that it's happened... So we need to delete those if they're there.
These are all the reasonable caveats that I can think of. I had a couple of unreasonable ones as well... see the obligatory https://xkcd.com/1172/
On Dec 11, 2015 7:05 AM, "Jonathan Druart" <jonathan.druart@bugs.koha-community.org <mailto:jonathan.druart@bugs.koha-community.org>> wrote:
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.htm...
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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
On 14 December 2015 6:14:22 am NZDT, Katrin Fischer <Katrin.Fischer.83@web.de> wrote:
I am in favour or removing the item-level_itype system preference and for centralizing all itemtype related code. But I think we have still have a need/use for the biblio level itemtype apart from it setting the default for the items level.
I know there was some work done to use it for holds related code. And also patches like document delivery (bug 14610) depend on it to allow requests for records without items.
Katrin
I agree, especially as more and more libraries have records with no items. (Think a catalogue for a website with the URL in 856u for marc21) Or all the project Gutenberg records etc. The item level item type is there for a reason. I'm all for simplifying the code but just want to make sure people understand it and don't kill features by accident. http://blog.bigballofwax.co.nz/2012/07/31/yes-you-should-rewrite-it-no-not-l... Chris
Am 12.12.2015 um 14:46 schrieb Barton Chittenden:
The rfc made sense to me; I think that it is the right approach. Here are a few things to consider:
1/ There are a *lot* of reports written that use items.itype. I don't like the fact that this isn't called items.itemtype, but unless we have a seamless and foolproof transition, this will cause massive amounts of pain. This includes the sql report library on the wiki.
2/ I think that there should be a method of locking the default itemtype to NULL so that it is not accidentally set by libraries who currently use item level itemtypes... Having that get set accidentally would be a pain to trouble-shoot.
3/ There are libraries who use item level itemtypes who currently have data in the biblioitems.itemtype... Just due to the fact that we haven't previously made it impossible, I'm sure that it's happened... So we need to delete those if they're there.
These are all the reasonable caveats that I can think of. I had a couple of unreasonable ones as well... see the obligatory https://xkcd.com/1172/
On Dec 11, 2015 7:05 AM, "Jonathan Druart" <jonathan.druart@bugs.koha-community.org <mailto:jonathan.druart@bugs.koha-community.org>> wrote:
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.htm...
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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org>
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Thanks all for your answers. I have played a bit with the code, and I would propose the following: 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?) 6/ drop column biblioitems.itemtype 7/ rename course_items.itype with course_items.item_type (to be consistent) Then we will have to replace the notices ^items.itype^items.item_type^ and ^biblioitems.itemtype^biblio.biblio_type^ should solve the problem. 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 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? 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@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.htm...
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
Hi Jonathan Il 17/12/2015 17:41, Jonathan Druart ha scritto:
I have played a bit with the code, and I would propose the following: [...] I would like some people engaged in the signoff process, not to let the patches in the signoff queue too long.
for sign-off you can count me. Bye Zeno Tajoli -- Zeno Tajoli /Dipartimento Sviluppi Innovativi/ - Automazione Biblioteche Email: z.tajoli@cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)
I promise to let you name one of the variables of the patches if you give me some feedbacks :) 2015-12-17 16:41 GMT+00:00 Jonathan Druart <jonathan.druart@bugs.koha-community.org>:
Thanks all for your answers.
I have played a bit with the code, and I would propose the following:
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?) 6/ drop column biblioitems.itemtype 7/ rename course_items.itype with course_items.item_type (to be consistent)
Then we will have to replace the notices ^items.itype^items.item_type^ and ^biblioitems.itemtype^biblio.biblio_type^ should solve the problem.
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
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?
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@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.htm...
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
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@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.htm...
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
Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
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@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.htm...
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
participants (9)
-
Barton Chittenden -
Chris Cormack -
Jonathan Druart -
Katrin Fischer -
Marc Véron -
Owen Leonard -
Paul A -
Tajoli Zeno -
Tomas Cohen Arazi