[Koha-bugs] [Bug 13937] Add a 'primary status' field for items

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Wed Apr 1 16:41:34 CEST 2015


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

Galen Charlton <gmcharlt at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gmcharlt at gmail.com

--- Comment #4 from Galen Charlton <gmcharlt at gmail.com> ---
(In reply to Kyle M Hall from comment #2)
> (In reply to Katrin Fischer from comment #1)
> > I am not sure about this idea - do we really need to store it in the
> > database as it is a calculated value? Or could it be something that is added
> > on export? 
> > Some libraries allow check-out of damaged items depending on severity - not
> > sure if the sequence is something that should/could be configurable.
> 
> It must have the ability to be stored in the MARC, otherwise it won't be
> useful. The problem is that external software utilizing z39.50 cannot
> determine the true status of an item based on the fields returned.

I'm +1 for the general idea of providing a unified item status value to
consumers of Koha APIs, Z39.50 clients, and metadata exports.

But responding to your response to Katrin's point: for the purpose of a Z39.50
client or a consumer of a MARC export, it doesn't need to be _stored_ in the
MARC record or in the items table; it only needs to be emitted when called for.
This could, for example, be invoked by EmbedItemsInMarcBiblio().  Another
option would be to have it be a derived DBIC virtual field.

Why not store it in an items.status column?  Because doing so automatically
creates more work: it would HAVE to be kept up to date whenever an item gets
modified or participates in a circulation transaction.  Why? You can't stop
folks from writing SQL queries on it, and you can't stop developers who are not
intimately familiar with Koha's notion of item status from trying to use it. To
put it another way, *storing* the calculated unified item status value in the
database means that you couldn't evade the scope creep of fixing all the item
status things in Koha.

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


More information about the Koha-bugs mailing list