Bug 2339 - Place hold button display with AllowOnShelfHolds OFF
Summary: Place hold button display with AllowOnShelfHolds OFF
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: rel_3_2
Hardware: PC All
: PATCH-Sent (DO NOT USE) critical (vote)
Assignee: Kyle M Hall
QA Contact:
URL:
Keywords:
Depends on:
Blocks: 6837
  Show dependency treegraph
 
Reported: 2008-07-10 12:49 UTC by Chris Cormack
Modified: 2019-06-27 09:24 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bugfix patch (13.17 KB, patch)
2009-07-29 15:04 UTC, Chris Cormack
Details | Diff | Splinter Review
Update to opac-ISBDdetail.pl to match the updated template. (1.82 KB, patch)
2009-07-30 11:59 UTC, Chris Cormack
Details | Diff | Splinter Review
screenshot of table with test cases (39.11 KB, image/png)
2009-08-12 09:39 UTC, Chris Cormack
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 00:50:02 UTC


---- Reported by jmf@liblime.com 2008-07-10 12:49:39 ----

The button to place holds shouldn't be visible on the results and detail pages for records that have no items on loan. It currently displays in all cases (with OPACItemHolds ON or OFF). On the reserve page, the only way it's blocked is that the button to initiate the actual hold is not available, so you can try to place a hold, but you can't actually submit it. This is very confusing to patrons, who don't understand why they can start the hold process, but not complete it. To fix this bug the following things need to happen when no items for a given record are on loan and AllowOnShelfHolds is OFF:

1. remove Place Hold on the results display in the OPAC (in both XSL and regular display)
2. remove Place Hold on the detail page in the OPAC
3. add a message on opac-reserve.pl to warn the patron that the item is not holdable (in case they try to hack the CGI to place it)



---- Additional Comments From jmf@liblime.com 2008-07-30 04:13:31 ----

I'm moving this one to rel_3_2, should be more easily solvable there. It would sure help if we had an XSL::Template.



---- Additional Comments From nengard@gmail.com 2008-10-25 12:14:02 ----

Where are we with this? I have a support ticket asking about this very problem.  

The ticket reads:

"The system is allowing holds to be placed on items that are available (checked in). Under preferences we have it marked to not allow holds on checked in items."



---- Additional Comments From mary.moules@liblime.com 2008-12-10 11:38:07 ----

This has also just been reported by one of my clients, who are also interested in the status of this issue.



---- Additional Comments From chris@bigballofwax.co.nz 2009-05-01 01:39:26 ----



*** This bug has been marked as a duplicate of http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3173 ***



---- Additional Comments From jwagner@ptfs.com 2009-05-01 15:38:08 ----

Chris, the fix I did in http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3173 only forces the other pages to obey the RequestOnOpac syspref, not the one in this call (OPACItemHolds).  Therefore that patch won't fix this call -- it shouldn't be marked as a duplicate.  The fix would be similar (modify the same templates), but it will have to be done separately.




---- Additional Comments From kyle.m.hall@gmail.com 2009-07-29 15:04:30 ----

Created an attachment
Bugfix patch





---- Additional Comments From gmcharlt@gmail.com 2009-07-30 01:31:28 ----

Pushed patch addressing item #2 (remove Place Hold on the detail page in the OPAC
).  Note that patch is not entirely complete - there are no code changes to opac-ISBDdetail.pl to match the changes to the ISBD template.

Items #1 and #3 are now moot; #1 because of the new functionality to place hold requests on multiple bibs from the search results; #3 because opac-reserves.pl now displays a message if there are no requestable items.



---- Additional Comments From kyle.m.hall@gmail.com 2009-07-30 01:38:32 ----

I will add another patch to update opac-ISBDdetail.pl



---- Additional Comments From kyle.m.hall@gmail.com 2009-07-30 11:59:06 ----

Created an attachment
Update to opac-ISBDdetail.pl to match the updated template.





---- Additional Comments From gmcharlt@gmail.com 2009-07-30 15:43:36 ----

Pushed followup patch.  This bug is now a candidate for testing and closure.



---- Additional Comments From nengard@gmail.com 2009-08-03 13:20:08 ----

I do not see the hold button when I shouldn't ;) this is good - but I want someone else to confirm by testing before I close this bug.



---- Additional Comments From katrin.fischer@bsz-bw.de 2009-08-12 09:39:41 ----

Created an attachment
screenshot of table with test cases

I did some tests with AllowOnShelfHolds OFF in OPAC and staff and I'm really happy with the results.

Tested configuration:

  - AllowOnShelfHolds OFF
  - OpacItemHolds OFF
  - AllowNotForLoanOverride: ON
  - ReservesNeedReturns ON
  - NOTFORLOAN = item type is not for loan
  - NORMAL = item can be checked out for 4 weeks

Please see screenshot for test cases and results.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:50 UTC  ---

This bug was previously known as _bug_ 2339 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2339
Imported an attachment (id=621)
Imported an attachment (id=622)
Imported an attachment (id=623)

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 jmf@liblime.com.
CC member bchurch@ptfs.com does not have an account here
CC member jwagner@ptfs.com does not have an account here
CC member mary.moules@liblime.com does not have an account here
The original submitter of attachment 621 [details] [review] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 622 [details] [review] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 623 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.