Holds not working in OPAC
Hi Amit, can you give some more details? Which error message is displayed? Item level or record level holds? Have you checked your settings for maxreserves, AllowOnShelfHolds, ...? Do you have a default rule definded for all libraries all itemtypes and all patron categories with an allowed number of holds > 0? I am resetting the version to master - 3.8 should only be used by the RM at the moment or later after release to file a bug specific for 3.8.
Katrin, it works if we setup a "default rule definded for all libraries all itemtypes and all patron categories with an allowed number of holds > 0". When such a rule is not defined, the error "sorry, none of the items can be placed on hold", also "title cannot be requested" is shown. The problem seems to be that in CanBookbeReserved: my @items = get_itemnumbers_of($biblionumber); #get items linked via host records my @hostitems = get_hostitemnumbers_of($biblionumber); foreach my $item (@items){ return 1 if CanItemBeReserved($borrowernumber, $item); }
Created attachment 9223 [details] Hold Request
Created attachment 9224 [details] [review] Holds not working in OPAC To test: - create circulation rules for branch only for example (Midway branch). - No need to set default circulation rules.
My comment above got truncated for some reason: Katrin, it works if we setup a "default rule definded for all libraries all itemtypes and all patron categories with an allowed number of holds > 0". When such a rule is not defined, the error "sorry, none of the items can be placed on hold", also "title cannot be requested" is shown. The problem seems to be that in CanBookbeReserved: my @items = get_itemnumbers_of($biblionumber); #get items linked via host records my @hostitems = get_hostitemnumbers_of($biblionumber); foreach my $item (@items){ return 1 if CanItemBeReserved($borrowernumber, $item); } CanItemBeReserved is expecting an itemnumber, but is receiving a hashref instead.
Doesn't this totally change the behaviour? - push (@items,@hostitems); + push (@hostitems,$items); Then - foreach my $item (@items){ + my %itemhash = %$items; + foreach my $item (keys %itemhash) { These are not equivalent, you are now totally ignoring the hostitems, whereas before it was looping over them
Created attachment 9393 [details] [review] Bug 7970 - Allow OPAC holds per library policy without default rule By default ReservesControlBranch systempreference is not inserting in systempreferences table. For this reason we have to set up default circulation rule for all libraries all itemtypes and all patron categories. After this we have to set only circulation rule by branch wise no need to set up for all libraries, itemtypes and patron categories. To Test: 1) Go to mysql use koha database 2) mysql> select * from systempreferences where variable = 'ReservesControlBranch'; +-----------------------+-----------------+-------------------------------+--------------------------------------+--------+ | variable | value | options | explanation | type | +-----------------------+-----------------+-------------------------------+--------------------------------------+--------+ | ReservesControlBranch | ItemHomeLibrary | ItemHomeLibrary|PatronLibrary | Patron can place a hold on the item. | Choice | +-----------------------+-----------------+-------------------------------+--------------------------------------+--------+
Hi Amit, I wrote a patch for bug 5795 to add the missing entry to the sql file. I think you are right, that we also need an updatedatabase. Would it perhaps be possible to check for existence of the system preference in the update? So we could avoid a red error message for users who already have the preference. The Patch for 5759 is signed off - but missing the update. How to proceed?
Hie, you can mark bug 5795 as duplicate of this one. > Would it perhaps be possible to check for existence of the system preference in the update? So we could avoid a red error message for users who already have the preference. I agree. Add an existence test in update and patch will be ok.
Amit - perhaps you could add another patch to update the database as follow-up to 5795?
Kartin, I am confuse if value already exists in database so we need to update database version?
Hi Amit, I think we have a problem here where some installations have the value and others not. Apparently it was missing from the syspref.sql file for a while, so new installations don't have the value. Older installations got it with an earlier database update.
Created attachment 9398 [details] [review] Update the database as follow-up to Bug 5795 Update the database as follow-up to Bug 5795 If value is not exist it insert new value other wise update the existing value. To Test: 1) Go to mysql use koha database 2) select * from systempreferences where variable = 'ReservesControlBranch'; 3) Show old result if value is present other wise it shows +-----------------------+-----------------+-------------------------------+-------------------------------------------------+--------+ | variable | value | options | explanation | type | +-----------------------+-----------------+-------------------------------+-------------------------------------------------+--------+ | ReservesControlBranch | ItemHomeLibrary | ItemHomeLibrary|PatronLibrary | Branch checked for members reservations rights. | Choice | +-----------------------+-----------------+-------------------------------+-------------------------------------------------+--------+
If value exists, why update it with the same value ? (see patch 9398) Note that even in a database where pref was missing at install, a change of it in intranet would create it in database. That's why if value exists, no need to do something. Someone agree ?
I agree that a change would create it and that thre is no need to change or udate if it already exists - I think this is what Amit's follow-up achieves, but have not tested it yet.
if (C4::Context->preference('ReservesControlBranch')){ my $sth = $dbh->prepare("UPDATE systempreferences SET value = ? WHERE variable = 'ReservesControlBranch'"); $sth->execute(C4::Context->preference('ReservesControlBranch')); } ... This part of patch updates pref with the same value.
Oh, I see it now, I think you are right, we only need to do something if it doesn't exist at all.
I agree no need to update it when it hasn't changed.
Created attachment 9450 [details] [review] Update the database as follow-up to Bug 5795 If sys pref ReservesControlBranch has null then update the table to insert a ItemHomeLibrary as value To Test: 1) Go to mysql use koha database 2) select * from systempreferences where variable = 'ReservesControlBranch'; Check if value set to ItemHomeLibrary. +-----------------------+-----------------+-------------------------------+-------------------------------------------------+--------+ | variable | value | options | explanation | type | +-----------------------+-----------------+-------------------------------+-------------------------------------------------+--------+ | ReservesControlBranch | ItemHomeLibrary | ItemHomeLibrary|PatronLibrary | Branch checked for members reservations rights. | Choice | +-----------------------+-----------------+-------------------------------+-------------------------------------------------+--------+
*** This bug has been marked as a duplicate of bug 5795 ***