https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20855 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@bugs.koha-c | |ommunity.org --- Comment #1 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Could you give us a step by step plan to recreate the problem? Can you have a look at the Koha log file, you will find a more meaningful error. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20855 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|17.11 |master Severity|minor |normal -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20855 Paul Hoffman <paul@flo.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |paul@flo.org --- Comment #4 from Paul Hoffman <paul@flo.org> --- Created attachment 77499 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=77499&action=edit Don't invoke _description_ on an undef itemtype -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20855 --- Comment #5 from Paul Hoffman <paul@flo.org> --- Sorry that my comment on the attachment was rather cryptic; this is only my first or second bug comment. I've upped the priority because the bug makes it impossible to view any list of holds (using waitingreserves.pl) that includes an item with NULL itype. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20855 --- Comment #7 from Paul Hoffman <paul@flo.org> --- I don't consider it a case of bad data -- as much as I would like to -- because itype (952 $y) is optional in the default framework. See installer/data/mysql/en/marcflavour/marc21/mandatory/marc21_framework_DEFAULT.sql, which sets marc_subfield_structure.mandatory to 0: 89 INSERT IGNORE INTO `marc_subfield_structure` (`tagfield`, `tagsubfield`, `liblibrarian`, `libopac`, `repeatable`, `mandatory`, `kohafield`, `tab`, `authorised_valu e`, `authtypecode`, `value_builder`, `isurl`, `hidden`, `frameworkcode`, `seealso`, `link`, `defaultvalue`) VALUES [...] 123 ('952', 'y', 'Koha item type', 'Koha item type', 0, 0, 'items.itype', 10, 'itemtypes', '', '', NULL, 0, '', '', '', NULL), -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20855 --- Comment #9 from Paul Hoffman <paul@flo.org> --- Well, bug 21150 presents a way to clean up bad data, but I consider it a bug that the bad data is allowed to exist in the first place. And, worse, that the bad data (while it exists) breaks waitingreserves.pl and (apprently) other scripts. An easy solution is for us is to update our frameworks so that they all require 952 $y -- we have item-level_itypes set to 1 ("Use the item type of the <specific item> as the authoritative item type"). But that seems like a band-aid solution. Frankly, my patch also strikes me as a band-aid solution, but at least it prevents waitingreserves.pl et al. from breaking. Here are some possible solutions that come to mind, with the pros and cons as I see them: (1) Check item-level_itypes at item creation time; if it is 1, require the subfield that maps to items.itype even if the framework's marc_subfield_structure.mandatory is 0. Pro: Prevents bad data from being created. Con: What happens when item-level_itypes is changed to 0 (biblio)? And then back again? Which it shouldn't, I know, but... (2) When item-level_itypes is changed, update marc_subfield_structure.mandatory to 1 for all frameworks. Pro: Prevents waitingreserves.pl et al. from breaking. Con: Not reversible. (3) At item creation time, allow NULL items.itype if the framework allows it. But when displaying items don't assume that they have an itype. That's what my patch does (or attempts to do!). Pro: Prevents waitingreserves.pl et al. from breaking. Con: Allows for bad data. But run search_for_data_inconsistencies.pl to fix that. (4) Something else that's a lot more complicated. :-( Pro: Presumably we can find The Right Way to fix this. Con: My head hurts trying to imagine how. Paul. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20855 koha-US bug tracker <bugzilla@koha-us.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla@koha-us.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20855 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #12 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- (In reply to Katrin Fischer from comment #11)

Should we mark this WONTFIX as we have agreed that the data inconsistency should be fixed instead?

Yes, done. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20855 Alexis Ripetti <alexis.ripetti@inLibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexis.ripetti@inLibro.com Status|RESOLVED |REOPENED Resolution|WONTFIX |--- --- Comment #13 from Alexis Ripetti <alexis.ripetti@inLibro.com> --- Hi, I reopen this bug because one of our client also encountered this problem and I think this needs to be patched because data inconsistency should not get a software error. This is not the first time that this probleme is reported and this will not be the last. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20855 Alexis Ripetti <alexis.ripetti@inLibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.