http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13937 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|gmcharlt@gmail.com |kyle@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13937 --- Comment #2 from Kyle M Hall <kyle@bywatersolutions.com> --- (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. -- You are receiving this mail because: You are watching all bug changes.

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.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13937 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris@bigballofwax.co.nz --- Comment #6 from Chris Cormack <chris@bigballofwax.co.nz> --- To echo Galen, the items are not stored in MARC .. we got rid of that in Koha 3.4 it's only exported to MARC when we are generating the MARC for zebra or an export. So yeah, adding it to the EmbedItemsInMarcBiblio() subroutine would make a lot of sense to me. Since that is the single point in Koha where items data is converted to MARC -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13937 --- Comment #7 from Heather Braum <hbraum@nekls.org> --- I'm not quite following the comments being made here -- forgive my ignorance on how MARC works with the Koha items table. TLDR version: Regardless of how this is developed and coded, will the final data field result be mappable to a MARC 952 subfield within Koha? It also is a status that needs to be constantly updated, in order for it to be used successfully by an external system. Long version: Background: Right now the not for loan, the lost, the damaged, and the withdrawn fields are separate items table subfields and mapped to the 952 field within MARC. Additionally, the in transit/on hold, waiting for pickup status of an item is stored elsewhere. NEKLS, SEKLS, and CKLS would like to develop an additional Koha field that is then possible to be mapped to a MARC 952 subfield so external systems are able to tell if an item is TRULY available for ILL (in our specific case); I'm sure there are other uses we haven't thought about. This new field would be able to aggregate the separate onloan, notforloan, withdrawn, lost, and damaged item fields, as well as pull in the separate data from the branchtransfers and reserves tables that indicate if an item is in transit and/or on hold waiting for pickup; it would need to be updated automatically -- not only on exports or when scripts are run. When we first looked into this last fall, we discovered that other ILSes typically have one MARC subfield where availability data is stored. Koha currently has the data that determines an item's availability stored all over the place. Right now, this external system profiles our systems using the 952$q field (items.onloan). That field isn't enough, obviously, to determine true availability; items that are on hold, in transit, lost, damaged, regularly appear on ILL request lists. Years ago, we asked about how to fix this problem, but were told a major rewrite of Koha would have to happen. Obviously, we've lived with the situation since. But Jason Robb at SEKLS started asking questions last fall, and we were told that this problem is possible to be fixed now. It was originally explained to us that this development could have greater impact on Koha in other places, too, but Kyle can explain that part much better. As long as we can map the outcome of where ever this data combining all of these statuses is stored to a MARC 952 item field, I don't care how it's developed :) But if the end result is that this new field is not going to be constantly updated and it can't be mapped to a MARC subfield, we may have to abandon this development. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13937 Nicole C. Engard <nengard@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|kyle@bywatersolutions.com |jweaver@bywatersolutions.co | |m CC| |nengard@gmail.com Status|NEW |ASSIGNED Change sponsored?|--- |Sponsored -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13937 --- Comment #9 from Jesse Weaver <jweaver@bywatersolutions.com> --- I've stolen this development from Kyle, and I have an idea for implementing it that could get us other benefits down the road. Instead of shoving this new status subfield into the MARC upon export to Zebra, why not just make a simple Z39.50 proxy using https://metacpan.org/pod/Net::Z3950::SimpleServer that will query Zebra and insert the item status information on its way back? This means that the item status information will always be up to date and the export remains simple. Also, once we bring in ElasticSearch, we won't have to keep Zebra around purely for Z39.50 (though we'll have to add some kind of PQF -> ElasticSearch translation layer to make this work). Thoughts? -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13937 --- Comment #11 from Heather Braum <hbraum@nekls.org> --- I added a version of this comment privately where we're tracking the development, but I'll go ahead and add it here publicly. As one of the development sponsors, if this feature is not going to be coded so it can be profiled to a MARC 952 item field, I can no longer support this development. I can't speak for the development co-sponsors, but we're all in the same boat with why we pursued and are funding this idea in the first place. We are specifically needing this new field to be able to be profiled to a MARC 952 item field to meet our needs (communicating accurate available/not available item status to an external ILL system that can only profile one MARC subfield using z3950 protocol). If that option is not feasible or supported, I'd consider this enhancement dead. If what Jesse is proposing still is able to be profiled to a MARC field in the end, then the above can be completely disregarded. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13937 Jesse Weaver <jweaver@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Add a 'primary status' |Add a Z39.50 daemon that |field for items |can inject item status MARC | |subfields -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13937 --- Comment #13 from Jesse Weaver <jweaver@bywatersolutions.com> --- Created attachment 46369 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=46369&action=edit Bug 13937 - Add a Z39.50 daemon that can inject item status MARC subfields This creates a new daemon, misc/z3950_responder.pl, which can respond to Z39.50 requests. By default, it just proxies searches to Zebra. If desired, however, it can also add a subfield to the item tags on outgoing records with a textual description of the item's status (checked out, lost, etc.). This is useful for certain ILL systems. These strings can be translated using the 'Z3950_STATUS' authorized value. Test plan: 1) Start the Z39.50 server using `perl misc/z3950_responder.pl`. 2) Connect to the server using `yaz-client 127.0.0.1:9999/biblios`. 3) Run a search, such as `find @attr 1=1016 book`. 4) Fetch the results both one at a time with `show 1` and in a batch using `show 1+5`. 5) Turn on MARCXML using `format xml` and `elements marcxml`, and verify that the records are still correctly fetched. 6) Enable the item status subfield by restarting the server with the option `--add-item-status=k`. 7) Search for and fetch records, and verify that a $k subfield is added to the item tags as appropriate. It should show some combination of "Checked Out", "Lost", "Not For Loan", "Damaged", "Withdrawn", "In Transit", or "On Hold" as appropriate, or "Available". 8) Add an authorized value named "Z3950_STATUS" with any of the keys "AVAILABLE", "CHECKED_OUT", "LOST", "NOT_FOR_LOAN", "DAMAGED", "WITHDRAWN", "IN_TRANSIT" or "ON_HOLD", and verify that their descriptions are used instead of the default values above. -- You are receiving this mail because: You are watching all bug changes.