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

[bugzilla-daemon at bugs.koha-community.org]

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

--- Comment #8 from Kyle M Hall <kyle at bywatersolutions.com> ---
Thanks Galen! That's a capital idea! I imagine then I would need to add a
system preference to decide which field/subfield that status value should go
into, right?

(In reply to Galen Charlton from comment #4)
> (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.