[Koha-bugs] [Bug 11617] Add itemnumber constraint to aqorders_items

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Mon Feb 3 10:49:11 CET 2014


http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11617

M. de Rooy <m.de.rooy at rijksmuseum.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Signed Off                  |In Discussion

--- Comment #7 from M. de Rooy <m.de.rooy at rijksmuseum.nl> ---
(In reply to Katrin Fischer from comment #3)
> I am wondering if we really should get rid of the acquisition information
> when deleting an item. When an item is deleted, it's moved to deleted_items
> and can still be looked up for reporting purposes. It might also be
> interesting at that point to find out about the other history of the item,
> acquisition history included.

Thanks for bringing that up, Katrin.
In the current codebase deleteditems is actually only used in tools/export.pl.
So like you mentioned, someone should use this connection in reporting. Note
that this is (somewhat) theoretical, but possible.
Koha currently removes the biblionumber from aqorders when a biblio is deleted
(talking about removing acquisition history..) Does that make keeping the
itemnumber in aqorders_items inconsistent? Or do we now stumble over the last
way to retrieve the biblionumber still, via this itemnumber :)

Also note that this discussion is in the scope of the AcqCreateItem pref. If
you set that to Cataloging, you will have no itemnumbers at all in
aqorders_items. That makes it a special table in the first place. The use of
this table is more or less only relevant during the acquisition stage and no
longer after ordering and receiving.

With that in mind, I have a slight preference for cleaning up this table if an
item is deleted. I will send a mail to the dev list and ask for some feedback.
Setting to In Discussion.

-- 
You are receiving this mail because:
You are watching all bug changes.


More information about the Koha-bugs mailing list