Because items may be created during cataloging or acquisitions before we know the item type, it's not practical to set a database constraint where items.itype is not NULL. However, if an item without an item type is checked out or a hold is placed on the item, either items.itype or biblioitems.itemtype (if we're using biblio level items) *must* be populated, or we'll trigger an internal server error. We should be checking for this when we set the notforloan status.
If the problem is acq items, maybe setting the itemtype not-mandatory for the ACQ framework but mandatory for every other would work? There is a lot more things that influence if an item can be checked out, not only the not-for-loan status.
(In reply to Katrin Fischer from comment #1) > If the problem is acq items, maybe setting the itemtype not-mandatory for > the ACQ framework but mandatory for every other would work? There is a lot > more things that influence if an item can be checked out, not only the > not-for-loan status. I'm not sure that will work: 1) If item-level_itypes is set to 'biblio record', items.itype may not be set at all, so we really need to test that one or the other is set. 2) Even if an item is in acquisitions, the library may want to the not-for-loan status to a negative number, making it available to be placed on hold... at that point, the item type needs to be set. That may well happen while the item is still in acquisitions.
Also, frameworks are editable, and I'd rather not have this be something that a user can disable.
We are now enforcing the itemtype to be mandatory.