[Koha-bugs] [Bug 20855] transferstoreceive.pl returns internal server error

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Tue Aug 7 15:52:23 CEST 2018


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20855

--- Comment #9 from Paul Hoffman <paul at 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.


More information about the Koha-bugs mailing list