[Bug 9516] New: Item Availability/Data missing from OPAC tag search
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9516 Bug ID: 9516 Summary: Item Availability/Data missing from OPAC tag search Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard@myacpl.org Reporter: dcook@prosentient.com.au For example: .../cgi-bin/koha/opac-search.pl?tag=Important&q=Important "Availability: No items available:" appears for each result, even if there actually are items available. This is because the raw marc is being retrieved straight from the database without having any item data embedded in it... If you do a regular search, you will get the correct item availability. I assume this is because Koha adds the item information to the MARCXML before passing it to Zebra which returns the item data inside the raw MARC... -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9516 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff Assignee|oleonard@myacpl.org |dcook@prosentient.com.au --- Comment #1 from David Cook <dcook@prosentient.com.au> --- Created attachment 14967 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=14967&action=edit Bug 9516 - Item Availability/Data missing from OPAC tag search Currently, an OPAC search using the "tag" and "q" query strings will have results with no item data. Next to "Availability", it will say "No items available:" (N.B. without reference to why the items are unavailable, like Checked out, In transit, etc.). The reason is that the opac-search.pl script is just pulling the marc blob straight from the database without embedding any item data. I've used the GetMarcBiblio sub with the embed item data option, and then converted the resulting Marc object to us marc using the "as_usmarc" method. --- To test: (Before patch) 1) Click on Tag cloud 2) Click on any of the tags 3) Note that all results say "Availability: No items available:" 4) Click on any result and note the actual status of the items for that biblio record (Apply patch) 1) Click on Tag cloud 2) Click on any of the tags 3) Note that the results actually have the correct item availability next to the "Availability" label. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9516 --- Comment #2 from David Cook <dcook@prosentient.com.au> --- Just another little note...make sure that the item availability information is actually correct for the items in your list. The data in my test system is a hodge-podge of backups, so I wasn't able to verify this one 100% (i.e. the item record says it's onloan, but there is no matching issue record, so it says checked out in the search results but available at the item level). Looking at the code, it should work, but doesn't hurt to keep a careful eye out. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9516 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #14967|0 |1 is obsolete| | --- Comment #3 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 15006 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=15006&action=edit Bug 9516 - Item Availability/Data missing from OPAC tag search Currently, an OPAC search using the "tag" and "q" query strings will have results with no item data. Next to "Availability", it will say "No items available:" (N.B. without reference to why the items are unavailable, like Checked out, In transit, etc.). The reason is that the opac-search.pl script is just pulling the marc blob straight from the database without embedding any item data. I've used the GetMarcBiblio sub with the embed item data option, and then converted the resulting Marc object to us marc using the "as_usmarc" method. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Appears to work as advertised. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9516 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off CC| |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=9516 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |RESOLVED Resolution|--- |INVALID --- Comment #4 from Kyle M Hall <kyle@bywatersolutions.com> --- Neither I nor Owen have been able to reproduce this bug. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9516 --- Comment #5 from Kyle M Hall <kyle@bywatersolutions.com> --- I should probably note that I forgot to test the pre-patch conditions before signing this patch. My bad! -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9516 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |WORKSFORME -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9516 --- Comment #6 from David Cook <dcook@prosentient.com.au> --- (In reply to comment #4)
Neither I nor Owen have been able to reproduce this bug.
Hmmm, intriguing! The more I look at the getRecords and searchResults subs, the more confused I get by the marc/marcxml/items synchronization. If it's working for you guys, it must mean that my sync is off, because using getRecords seems to return raw marc with embedded item data, while just querying the marc blob in the database returns raw marc without item data. :S I thought that the marcxml and marc weren't supposed to store item-level data anymore, but I don't see in these subs where it is being added. In fact, in searchResults (around line 1729: "Pull out the items fields"), it seems that the incoming marcRecord param passed into searchResults should have that embedded item data :S. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9516 --- Comment #7 from Kyle M Hall <kyle@bywatersolutions.com> --- I think it may be a good idea to get at least a couple more people to test the preconditions for this bug. (In reply to comment #6)
(In reply to comment #4)
Neither I nor Owen have been able to reproduce this bug.
Hmmm, intriguing!
The more I look at the getRecords and searchResults subs, the more confused I get by the marc/marcxml/items synchronization.
If it's working for you guys, it must mean that my sync is off, because using getRecords seems to return raw marc with embedded item data, while just querying the marc blob in the database returns raw marc without item data.
:S
I thought that the marcxml and marc weren't supposed to store item-level data anymore, but I don't see in these subs where it is being added. In fact, in searchResults (around line 1729: "Pull out the items fields"), it seems that the incoming marcRecord param passed into searchResults should have that embedded item data :S.
-- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9516 --- Comment #8 from David Cook <dcook@prosentient.com.au> --- I agree. I'm still not sure how it could've worked for you. When I connect to Zebra using yaz, I notice that the 952 field has been appended to the record, which is to be expected. When I look at the marc blob in the database, I don't see any 952 field, which is also to be expected. Since the GetBiblioData sub doesn't embed item data, I don't see how your your opac tag search results could possibly be getting item data :S. When you do the test, is your query string something along the lines of: ?tag=KEYWORD&q=KEYWORD Alas, I cannot test anything search related on my git dev install, as Zebra doesn't work on it. Wish I knew why... But when I try it on my actual trial install (3.8.0), it doesn't get any item data. I've looked at the code for master, and it looks like the same as 3.8.0 in this regard :S. (In reply to comment #7)
I think it may be a good idea to get at least a couple more people to test the preconditions for this bug.
(In reply to comment #6)
(In reply to comment #4)
Neither I nor Owen have been able to reproduce this bug.
Hmmm, intriguing!
The more I look at the getRecords and searchResults subs, the more confused I get by the marc/marcxml/items synchronization.
If it's working for you guys, it must mean that my sync is off, because using getRecords seems to return raw marc with embedded item data, while just querying the marc blob in the database returns raw marc without item data.
:S
I thought that the marcxml and marc weren't supposed to store item-level data anymore, but I don't see in these subs where it is being added. In fact, in searchResults (around line 1729: "Pull out the items fields"), it seems that the incoming marcRecord param passed into searchResults should have that embedded item data :S.
-- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org