---- Reported by bchurch@ptfs.com 2008-09-30 11:27:48 ---- When a requested item is checked in and being held for a patron, the item's status shows as "available" in OPAC. It also shows as "available" on the results list in the staff client. The correct status shows on the bib detail window in the staff client. This is extremely confusing for patrons and staff because the item isn't really available. Patrons are going to the shelves expecting to find the item. The available status should mean that the item is in the library and can be checked out. This log is being submitted on the behalf of a client. ---- Additional Comments From joe.atzberger@liblime.com 2009-01-22 11:46:30 ---- The STAFF interface now shows correct Availability on details page like: "Waiting for John Smith at West Branch Library since 01/29/2009" However, on the STAFF hitlist, the same item is still counted in the "Available" list. The OPAC still just says "Available". ---- Additional Comments From oleonard@myacpl.org 2009-02-17 11:27:20 ---- Just to be clear about the severity of the problem: The public will see "Available" for any items which are "waiting" on the holds shelf. That means a trip to the shelf to look for the item and then a trip to the desk to ask why it isn't there. The staff will be similarly confused if they aren't careful to click through to the detail page. NPL would very much like to see this resolved. ---- Additional Comments From adrea@moablibrary.org 2009-02-18 06:42:35 ---- Our library is getting ready to go live with KOHA in March, and we would also very much like to see this bug fixed asap. As a public library we deal with a large number of holds. Patrons are going to find this bug confusing and staff are going to find it extremely annoying. In our opinion "available" should only apply to materials which a patron can come into the library and check out. Our current ILS displays holds on the hold shelf with the status "On Hold." If there is a problem and staff need to locate an item, they can immediately tell where to look. Patrons looking at the OPAC at home or in the library know that they can get in line for the material by placing their own hold. Here is a summary of what happens when we place a hold. Placed item on hold for patron... OPAC search screen – shows Availability: Copies available: Moab Library Adult Fiction Book [F BROOKS] (1), OPAC details screen Status – Available Staff Mod search screen- 1 item 1 available: • Moab Library Adult Fiction Book [F BROOKS] (1) Staff Mod details- On hold for Adrea Lund expected at Moab Library since 02/13/2009 Went to shelf – got item and checked it in... OPAC – same as above for both views Staff Mod search screen – same as above Staff Mod details screen- Waiting for Adrea Lund at Moab Library since 02/13/2009 Thanks, Adrea ---- Additional Comments From jstanley@hpplnj.org 2009-02-18 07:18:36 ---- This is more than a minor inconvenience. We have several patrons who have checked the status of a book from home, come in to try get it multiple times without ever asking for help from library staff. One of them became very angry, demanding to know when this would be fixed, implying that tomorrow would not be soon enough. It makes us look bad, a position we don't like being in during difficult funding years. The HPPL would also really like to see this bug fixed, and soon. ---- Additional Comments From mason@katipo.co.nz 2009-02-23 19:22:13 ---- I can confim that this issue is fixed in the latest stable release (Koha version: 3.00.01.005) the catch here folks, is that availability info for the items is pulled from zebra, not the items table. (this is a performance feature) sooo, make sure you have your zebraqueue daemon running when testing this (else you will get incorrect results) and give zebra a minute to index the availability info, too ---- Additional Comments From mason@katipo.co.nz 2009-02-23 19:24:11 ---- Created an attachment screenshot ---- Additional Comments From oleonard@myacpl.org 2009-02-24 05:55:26 ---- Mason, is that attachment supposed to show a working example? That screenshot shows only available and checked-out items, not waiting holds. ---- Additional Comments From adrea@moablibrary.org 2009-02-25 09:09:17 ---- Our project manager from Liblime is using version 3.01.00.013 and this bug still exists in that version. Our library has a question related to this bug - does this bug causes "hold filled" emails to be sent out at inappropriate times? We have not yet gone live using KOHA, we are worried that patrons who are actually next in line will get an email when an item is on the hold shelf waiting for the person ahead of them in the hold list. ---- Additional Comments From mason@katipo.co.nz 2009-02-25 10:59:20 ---- (In reply to comment #7) > Mason, is that attachment supposed to show a working example? That screenshot > shows only available and checked-out items, not waiting holds. > Bah, I updated the wrong bug here. Looks like this issue is still outstanding :/ ---- Additional Comments From oleonard@myacpl.org 2009-04-06 13:50:36 ---- Created an attachment Partial fix, dealing with opac-detail only GetItemsInfo() returns a count_reserves variable which may be "Waiting" or "Rese rved," but opac-detail.pl didn't include a check for these possibilities. This p atch has opac-detail.tmpl output "On hold" in either case. ---- Additional Comments From gmcharlt@gmail.com 2009-04-08 18:15:30 ---- Pushed opac-detail.pl patch to HEAD. ---- Additional Comments From nengard@gmail.com 2009-04-14 11:29:16 ---- Sorry - I closed cause the patch worked - but then re-read that it was only a partial patch. ---- Additional Comments From jwagner@ptfs.com 2009-05-12 16:01:49 ---- I'm on the latest koha.org (3.01.00.031) but I don't see any fix either in staff or OPAC. If I'm understanding the discussion, Owen's patch should have fixed the OPAC results list. I still see Available there but On Hold in the details page. ---- Additional Comments From oleonard@myacpl.org 2009-05-12 17:09:58 ---- > If I'm understanding the discussion, Owen's patch should have > fixed the OPAC results list. No, my patch only addressed opac-detail.pl ---- Additional Comments From gcollum@gmail.com 2010-02-21 00:09:29 ---- Created an attachment Propose patch. Fixes opac results if data transformed thru xsl. ---- Additional Comments From gcollum@gmail.com 2010-02-21 01:14:49 ---- Created an attachment Propose patch. Follow-up patch. - Fixes opac (no xsl) and intranet. ---- Additional Comments From gmcharlt@gmail.com 2010-02-22 01:26:11 ---- Pushed patches from Garry Collumn to HEAD. Please test. ---- Additional Comments From dschust1@gmail.com 2010-04-29 16:11:41 ---- (In reply to comment #17) > Pushed patches from Garry Collumn to HEAD. Please test. > Still a problem http://screencast.com/t/NjJkN2YzMT - from IRC chat today --- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:54 UTC --- This bug was previously known as _bug_ 2655 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2655 Imported an attachment (id=775) Imported an attachment (id=776) Imported an attachment (id=777) Imported an attachment (id=778) Actual time not defined. Setting to 0.0 The original reporter of this bug does not have an account here. Reassigning to the person who moved it here: chris@bigballofwax.co.nz. Previous reporter was bchurch@ptfs.com. CC member adrea@moablibrary.org does not have an account here CC member gveach@seuniversity.edu does not have an account here CC member jstanley@hpplnj.org does not have an account here CC member jwagner@ptfs.com does not have an account here CC member rch@liblime.com does not have an account here CC member stevens@ci.salinas.ca.us does not have an account here CC member thehaven104@gmail.com does not have an account here The original submitter of attachment 775 [details] is unknown. Reassigning to the person who moved it here: chris@bigballofwax.co.nz. The original submitter of attachment 776 [details] [review] is unknown. Reassigning to the person who moved it here: chris@bigballofwax.co.nz. The original submitter of attachment 777 [details] [review] is unknown. Reassigning to the person who moved it here: chris@bigballofwax.co.nz. The original submitter of attachment 778 [details] [review] is unknown. Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
Im confused, that screencast seems to show it working just fine. It also appears to work fine in the latest checkout of master, if something is waiting it doesnt show as available. Can someone else please test and confirm so we can close this.
I confirm that this is working right and that it worked right in the screencast - closing.