http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13937 Galen Charlton <gmcharlt@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gmcharlt@gmail.com --- Comment #4 from Galen Charlton <gmcharlt@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.