The amountoutstanding value set by GetMemberDetails was only used in a
few places. In that case it makes sense to only retrieve it when needed.
Test plan:
1/ Add fines to a patron, on the OPAC patron info page, you should see a
"Fines" tab
2/ Add credit to a patron, you should see the credit displayed
3/ Set the pref maxoutstanding to 3
4/ Add a fine of 4 to a patron
5/ Try to place an hold for this patron
=> You should get a "too much oweing" message
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The correct way to get the value of BlockExpiredPatronOpacActions from a
patron object is to get the patron category then call the
effective_BlockExpiredPatronOpacActions:
$patron->category->effective_BlockExpiredPatronOpacActions
So this patch applies this change and remove this value from the
GetMemberDetails subroutine.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jason M. Burds <JBurds@dubuque.lib.ia.us>
Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>
This patch adds logging for several holds actions. Specifically for:
- CREATE
- CANCEL
- DELETE
- RESUME
- SUSPEND
- MODIFY
To test:
- Enable the HoldsLog syspref
- Add a hold on a record/item
=> SUCCESS: The log view shows the CREATE action
- Click on the <Suspend> button
=> SUCCESS: The log view shows the SUSPEND action
- Click on the <Unsuspend> button
=> SUCCESS: The log view shows the RESUME action
- Click on the red cross, to delete the hold
=> SUCCESS: The log view shows the CANCEL action
Note: The DELETE action is logged when DelMember is called, with bug 16819 patches applied.
Sponsored-by: NEKLS
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
I also wonder about this going in defaulted on, but since the other logs are as well it seems ok to me.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
In order to move IsMemberBlocked to Koha::Patron it makes sense to move
the code from Koha::Patron::Debarments::IsDebarred to
Koha::Patron->is_debarred.
Test plan:
1/ Add a restriction to a patron
2/ make sure he is not able to checkout items any more
3/ Make sure he cannot get a discharge
4/ Put a hold and make sure you get "Patron has restrictions"
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Some libraries would like the ability to select the itemtype to request
when placing holds. For example, if a record has 3 copies of BookA and 3
copies of BookA in large print, this feature would allow a person to
place a hold on the record, but still be able to target only the Large
Print edition so that the first Large Print copy that becomes available
is targeted, rather than forcing the patron to select a particular copy
to hold.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Create a record with items of two or more itemtypes
4) Place a record level hold on the record while choosing one particular
itemtype
5) Check in an item from the record that is not of that itemtype
6) Notee it is not trapped for the hold
7) Check in an item from the record that does match the selected itemtype
8) Note the item is trapped for the hold
Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se>
Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The 'borrower' should not be used anymore, especially for new code.
This patch move files and rename variables newly pushed (i.e. in the Koha
namespace).
Test plan:
1/
git grep Koha::Borrower
should not return code in use.
2/
Prove the different modified test files
3/ Do some clicks in the member^Wpatron module to be sure there is not
an obvious error.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as described. Tested with Circulation, Members/Patrons, Discharge,
Restrictions modules and the must common functionalities
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
The singleBranchMode system preference does not make sense.
Either the install has only 1 library defined or several. In both case,
we can easily guess the behavior to follow.
So the idea of this patch is to replace the fetch of this syspref with a
call to count the number of libraries defined in DB.
Test plan:
1/ From a fresh Koha install, execute the DB entry to remove the pref.
2/ Define only 1 library
3/ Confirm that Koha behaves the same as before (try to change your
library, look at the facets)
4/ Create another library (or more) and reinsert the pref and set it:
insert into systempreferences (variable, value)
values('singleBranchMode', 1);
5/ Execute the DB entry
You should get a warning message.
6/ Repeat 3.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Does what it says, but will change behaviour for any Koha install that
has 2 branches defined, One circulation, and this preference set.
If that is an acceptable change, we might need to make sure this is noted well in the
release notes.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Remove C4::Dates from files:
- opac/opac-memberentry.pl
- opac/opac-reserve.pl
- opac/opac-search-history.pl
- opac/opac-showreviews.pl
- opac/opac-suggestions.pl
- opac/opac-serial-issues.pl
- opac/opac-alert-subscribe.pl
- opac/opac-ics.pl
To test:
- Apply patch
- Verify, that self registration and holds work as before
- Verify that tabs in catalog item detail work and display
as before
- For serials: Verify that subscriptions work as before. It is a
little bit hidden, in tab Subscriptions, then 'More details', then
tab 'Brief history', button 'Subscribe to email notificatin on
new issues'
- For ics: Can not be tested at the moment, not yet used (Bug 5456),
pls. have a look at the code changes
(Amended following comment #2)
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
- opac-suggestions.pl
- opac-readingrecord.pl
- opac-reserve.pl
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Koha is currently not engineered to handle multiple holds per record.
Until such time that is does, we should not allow them to be created.
Test Plan:
1) Apply this patch
2) Log in to the opac
3) Place a hold
4) Hit the back button on your browser
5) Place the hold again
6) Note the new message
Signed-off-by: David Kuhn <kuhn@monterey.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
In order no to slow too much the browsing, it is certainly not a good
idea to add this cache-control value for all pages at the OPAC.
This patch just adds where the author found it could be useful.
Test plan:
1/ Login at the OPAC
2/ Go on the account page (opac/opac-account.pl)
3/ Click log out
4/ Use the back button of your browser
Without this patch you will see the previous page.
With this patch, the previous page will be reloaded and you will be
redirected to the login form.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
The call to GetReserveFee in opac-reserve.pl is useless in its current
form. The first parameter undef takes care of receiving 0.
But note that the user is warned correctly for the charge via param
variable RESERVE_CHARGE on the opac form.
When the hold is placed, AddReserve calls GetReserveFee. So if the routine
would work correctly, we would not need this extra call in opac-reserve
in the whole place. Unfortunately, the routine is not working correctly.
I will submit a fix for GetReserveFee under a new report (14702).
Test plan:
[1] Add a hold fee to some category.
[2] Check the warn for placing a hold on such a book in OPAC.
[3] Observe that the actual fee is not charged. This is a current bug and
it will be addressed on report 14702.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test Plan:
1) Apply this patch set
2) prove t/db_dependent/Circulation.t
3) prove t/db_dependent/Holds.t
4) prove t/db_dependent/Holds/LocalHoldsPriority.t
5) prove t/db_dependent/Holds/RevertWaitingStatus.t
6) prove t/db_dependent/HoldsQueue.t
7) prove t/db_dependent/Reserves.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
AMENDED: An else branch in reserve/placerequest.pl was removed. This had
the effect of making it no longer possible to place an any hold in the
staff client.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Verified placing a biblio level and an item level hold.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The borrow permission was used but uselessly.
For instance, at the opac, the flagsrequired parameter was set to
'borrow' but the 'authnotrequired' was set also (which means no auth
required).
At the end, this permission was used at only 1 place: for the basket,
intranet side.
This can be replaced with the catalogue permission (which is used to
search).
Test plan:
1/ Confirm that you are able to show/download/sent the cart (intranet side)
with the catalogue permission.
2/ At the OPAC, you should be able to access the same pages as before
with any other permissions.
Concretely it is quite difficult to test this patch, you should have a
look at the code.
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This is a followup for Bug 14186 that removes the extraneous tab
char on line 470, so that the patch can clear QA tools.
This patch sets $reservedfor to an empty string.
Test plan
=========
1/ in a terminal, run `tail -f ` on your instance's opac-error.log
2/ go to the opac and search from an item that exists on the Koha
instance.
3/ Select the title (if more than one title is returned) and click on
'Place hold' link to go to opac-reserve.pl
4/ notice the warning - "opac-reserve.pl: Use of uninitialized value
$reservedfor" appear in the `tail`ed opac-error.log
5/ apply the patch
6/ reload the page (opac-reserve.pl)
7/ page works but the warning in step #4 is no longer thrown up
8/ run qa test (i.e. koha-qa.pl -c 1 -v 2), there should be no error
Remarks: Testing result match expected test plan output. The QA tests
pass with "OK" for the commit.
Signed-off-by: Indranil Das Gupta (L2C2 Technologies) <indradg@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch sets $reservedfor to an empty string.
Test plan
=========
1/ in a terminal, run `tail -f ` on your instance's opac-error.log
2/ go to the opac and search from an item that exists on the Koha
instance.
3/ Select the title (if more than one title is returned) and click on
'Place hold' link to go to opac-reserve.pl
4/ notice the warning - "opac-reserve.pl: Use of uninitialized value
$reservedfor" appear in the `tail`ed opac-error.log
5/ apply the patch
6/ reload the page (opac-reserve.pl)
7/ page works but the warning in step #4 is no longer thrown up
8/ run qa test (i.e. koha-qa.pl -c 1 -v 2), there should be no error
Remarks: The QA test failed - "forbidden pattern: tab char (line 470)".
Marking this as 'FAILED QA'
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This way ILS-DI HoldItem and HoldTitle services also benefit from this
check
Test plan:
1/ Define some default holds policies by item type in
/admin/smart-rules.pl
2/ Use ILS-DI HoldItem service and check that those rules are respected
3/ Check that staff and opac hold behaviour is unchanged regarding
these rules.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes tests and QA script. No regressions found,
improves the ILS-DI HoldItem response.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
To test:
1)
Prepare an URL that put's a hold in OPAC (see comment #1), e.g.
[YOUR SERVER]/cgi-bin/koha/opac-reserve.pl?biblionumbers=1
2)
Set system preference 'RequestOnOpac' to 'Don't allow patrons to place holds on items from the OPAC.'
3)
Go diectly to this URL.
Result: The page displays to confirm hold (wrong)
4)
Apply patch
5)
Repeat step 3
Result: Redirect to 404 page (OK)
6)
Set system preference to "Allow"
7)
Repeat step 3
Result: The page displays to confirm hold (OK), like it would be from link in OPAC.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
http://bugs.koha-community.org/show_bug.cgi?id=9987
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
C4::Reserves:
* Added OnShelfHoldsAllowed() to check issuingrules
* Added OPACItemHoldsAllowed() to check issuingrules
* IsAvailableForItemLevelRequest() changed interface, now takes
$item_record,$borrower_record; calls OnShelfHoldsAllowed()
opac/opac-reserve.pl and opac/opac-search.pl:
* rewrote hold allowed rule to use OPACItemHoldsAllowed()
* also use OnShelfHoldsAllowed() through
* IsAvailableForItemLevelRequest()
templates:
* Removed AllowOnShelfHolds and OPACItemHolds global flags, they now
only have meaning per item type
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
I have tested this patch left, right and upside down for the last
several months. All tests have passed.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
No matter what the selection of OPACShowHoldQueueDetails is, if it is
enabled it displays a line "Holds and priority:" even if you've opted to
hide one of those!
Test Plan:
1) Apply this patch
2) Test each setting of OPACShowHoldQueueDetails
3) Ensure each setting displays the correct fields ( or lack thereof )
Signed-off-by: Christopher Brannon <cbrannon@debian.localdomain>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This is the same issue as bug 12134.
Test Plan:
1) Add a manual restriction to a patron with expiration date in the past
2) Go on the OPAC and connect
3) Try to add an hold on a record (opac-reserve.pl)
3) Note the warning message
"Sorry, you cannot place holds because your account has been frozen ..."
4) Apply this patch
5) Repeat step 2
6) Note the warning message does not appear anymore
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Makes code cleaner, also works as described.
NOTE: If you set a debarment with date in the past in the GUI,
there will be no entry in borrowers.debarred and you won't be
able to see the problem. Set one with a date in the future and
then alter the date in borrower_debarments and borrowers.debarred.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch changes the way CanBookBeReserved() and CanItemBeReserved() return error
messages and how they are dealt with in the templates. This change makes it possible
to distinguish between different types of reservation failure.
Currently only two types of errors are handled, all the way to the user, from the CanItemBeReserved():
-ageRestricted
-tooManyReserves which translates to maxreserves
#############
- TEST PLAN -
#############
((-- AGE RESTRICTION --))
STAFF CLIENT
1. Find a Record with Items, update the MARC Subfield 521a to "PEGI 16".
2. Get a Borrower who is younger than 16 years.
3. Place a hold for the underage Borrower for the ageRestricted Record.
4. You get a notification, that placing a hold on ageRestricted material is
forbidden. (previously you just got a notification about maximum amount of reserves reached)
((-- MAXIMUM RESERVES REACHED --))
0. Set the maxreserves -syspref to 3 (or any low value)
STAFF CLIENT AND OPAC
1. Make a ton of reserves for one borrower.
2. Observe the notification about maximum reserves reached blocking your reservations.
((-- MULTIPLE HOLDS STAFF CLIENT --))
3. Observe the error notification "Cannot place hold on some items"
((-- MULTIPLE HOLDS OPAC --))
1. Make a search with many results, of which atleast one is age restricted to the current borrower.
2. Select few results and "Place hold" from to result summary header element.
(Not individual results "Place hold")
3. Observe individual Biblios getting the "age restricted"-notification, where others can be
reserved just fine.
Updated the unit tests to match the new method return values.
t/db_dependent/Holds.t & Reserves.t
Followed test plan. Works as expected and displays meaningful messages for the reason why placing a hold is not possible.
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since the bootstrap OPAC's place hold interface doesn't use tables
there is no use for the colspan calculation being done in the script.
This patch removes it.
To test, place one or more holds in the OPAC and confirm that there are
no display problems. The OPAC error logs should show no associated
error.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No display problems, no related errors on log, no koha-qa errors
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes tests and QA script, no regressions found.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Re-add the system preference maxreserves.
All the code using maxreserves is still in place. Though it
is not used in the Reserves module, it is used in all the
scripts where holds are placed.
Also adds a check so that a borrower cannot exceed the maximum
number of allowed holds by using the multi-hold feature via
the opac.
Test Plan:
1) Apply this patch
2) Run updatedatabase
3) Set maxreserves to 3, set opactheme to bootstrap
4) Log into the opac as a patron
5) Place 3 holds
6) Attempt to place a 4th hold
7) Note you get an error message and cannot place a forth hold
8) Delete two of those holds
9) Attempt to place 3 or more holds as a multi-hold
10) You should see a warning that you cannot place this many holds
11) Try to anyway
12) You should see an alert to tell you to reduce the number of holds
you are placing.
13) Reduce the number for holds you are placing to 2
14) Your holds should now be placed
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
A dollar sign is hard-coded in opac-reserve.pl and becomes apparent when trying to place a reservation
when one has "too_much_oweing" or too much fines.
Removing the dollar sign so we just get
<"Käyttömaksujen katto ylitetty. Et voi tehdä varauksia. Sinulla on maksamattomia maksuja 9.50.">
instead of
<"Käyttömaksujen katto ylitetty. Et voi tehdä varauksia. Sinulla on maksamattomia maksuja $9.50.">
Patch removes hard coded $ sign.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
The dollar sign is gone and the message still displays correctly.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since we switched to Template Toolkit we don't need to stick with the
sufix we used for HTML::Template::Pro.
This patch changes the occurences of '.tmpl' in favour of '.tt'.
To test:
- Apply the patch
- Install koha, and verify that every page can be accesed
Regards
To+
P.S. a followup will remove the glue code.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Test Plan:
1) Apply patch
2) Run updatedatabase.pl
3) Pick a patron, note the patron's category
5) Issue an item to this patron
4) Edit that category, set "Block expired patrons" to "Block"
5) Verify the patron cannot renew or place holds in the OPAC
6) Edit the category again, set "Block expired patrons" to
"Don't block"
7) Verify the patron *can* renew and place holds in the OPAC
8) Edit the category again, set "Block expired patrons" to
"Follow system preference BlockExpiredPatronOpacActions"
9) Set the system preference BlockExpiredPatronOpacActions to
"Block"
10) Verify the patron cannot renew or place holds in the OPAC
11) Set the system preference BlockExpiredPatronOpacActions to
"Don't block"
12) Verify the patron *can* renew and place holds in the OPAC
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Melia Meggs <melia@bywatersolutions.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Testing notes on last patch in series.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This parameter is a boolean, if true, the hours won't be displayed if
the time is 23:59 (24hr format) or 11:59 PM (12hr format).
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
There are 2 useless routines in the Koha::DateUtils
module:output_pref_due and format_sqlduedatetime. We can call
output_pref and format_datetime with dateonly = 0.
format_sqlduedatetime is only used in one place: opac-reserve.pl
Test plan:
1/ Verify on the opac-reserve.pl page that the date is correctly
displayed for for onloan items (you should use the "specific copy"
feature).
2/ Launch prove t/DateUtils.t UT file and verify all UT pass.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Due date on opac-reserve shown correctly. Unit tests pass.
Did a grep on both function names.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
No references to subs found. Passes koha-qa.pl, t and xt
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The return from GetReservesFromBiblionumber contains an unnecessary
extra variable. In scalar context an array returns its element count.
Maintaining a separate count can lead to unforeseen bugs
and imposes ugly constructions on the subroutine's users.
Remove the useless count variable from the return
This patch also changes the parameters: now the routine takes a hashref.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Placed biblio holds, future holds and item holds. Works as expected.
Tested Holds.t and Reserves.t. Pass.
Tested /cgi-bin/koha/ilsdi.pl?service=GetRecords&id=999 with two holds on
one item. Fine.
C4/SIP/ILS/Item.pm: Looked for "whatever" and "arrayref" and could not find
them anymore. Looks good.
Handled a few unneeded calls in QA follow-up.
Left only one point to-do for serials/routing-preview.pl. See Bugzilla.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
1/ CURRENT_DATE() is a MySQLism and should be replaced with CAST(now() AS
DATE).
2/ The date formatting should be done in the template (using the TT
plugin).
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Before bug 9788 the alldates parameter of GetReservesFromItemnumber was
actually not used in the codebase.
The first patch of bug 9788 did change that and passed true by default.
But a closer look revealed that we do not really need it.
The parameter is removed by this patch; the SQL statement is slightly
adjusted: if reservedate<=now or a waitingdate is filled for the
requested itemnumber, GetReservesFromItemnumber will return the reserve.
This includes so-called future waits: a future hold that has been confirmed
ahead of time with pref ConfirmFutureHolds > 0 days.
Note that future item-level holds are not really interesting to return; this
just corresponds to original behavior. Future next-available holds are not
in view at all; they do not contain an item number.
Test plan:
Actually, the test plan of the first patch is valid. But for completeness I
repeat it here:
[1] Enable future holds and set ConfirmFutureHolds to 2 days.
[2] Place a future next-available hold for 2 days ahead.
[3] Check item status on catalogue detail. Available? That is fine.
[4] Confirm the future hold by checking it in. ('future wait')
[5] Look at item status again on catalogue detail. Must be Waiting now.
[6] Switch to OPAC and login as another opac user. Goto Place a hold.
[7] Check item status with item level hold info. Is it waiting?
[8] Try to place hold in staff, check item level status again. Waiting?
[9] Make a transfer for the item. Switch branch. Check hold status on
Transfers to receive.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch makes GetReservesFromItemnumber also returns the waiting
date and removes some repeated code.
Improves item status display on catalogue detail, when placing a hold at
opac-reserve and in staff, and on transfers to receive form.
This patch builds on work from reports 9367 and 9761.
Test plan:
Place a future next-av. hold (enable future holds prefs), say 2 days ahead.
Check item status on catalogue detail. Nothing to see.
Enable ConfirmFutureHolds by inserting a number of days, say 2.
Confirm earlier hold by checking it in. Look at item status again on detail.
Switch to other opac user. Try to place a hold again. Check item status with
item level hold info. Try to place hold in staff, check item level status.
Make a transfer for that item. Switch branch. Look at transfers to receive.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds a more extensible and flexible debarments system to Koha. The fields
borrowers.debarred and borrowers.debarredcomment are retained for compatibility and
speed.
This system supports having debarments for multiple reasons. There are currently
three types of debarments:
OVERDUES - Generated by overdue_notices.pl if the notice should debar a patron
SUSPENSION - A punative debarment generated on checkin via an issuing rule
MANUAL - A debarment created manually by a librarian
OVERDUE debarments are cleared automatically when all overdue items have been returned,
if the new system preference AutoRemoveOverduesRestrictions is enabled. It is disabled
by default to retain current default functionality.
Whenever a borrowers debarments are modified, the system updates the borrowers debarment
fields with the highest expiration from all the borrowers debarments, and concatenates
the comments from the debarments together.
Test plan:
1) Apply patch
2) Run updatedatabase.pl
3) Verify the borrower_debarments table has been created and
populated with the pre-existing debarments
4) Run t/db_dependent/Borrower_Debarments.t
5) Manually debar a patron, with an expiration date
6) Verify the patron cannot be issued to
7) Add another manual debarment with a different expiration date
8) Verify the 'restricted' message lists the date farthest into the future
9) Add another manual debarment with no expiration date
10) Verify the borrower is now debarred indefinitely
11) Delete the indefinite debarment
12) Verify the debarment message lists an expiration date dagain
13) Enable the new system preference AutoRemoveOverduesRestrictions
14) Set an overdue notice to debar after 1 day of being overdue
15) Check out an item to a patron and backdate the due date to yesterday
16) Run overdue_notices.pl
17) Verify the OVERDUES debarment was created
18) Return the item
19) Verify the OVERDUES debarment was removed
20) Disable AutoRemoveOverduesRestrictions
21) Repeat steps 15 though 18, verify the OVERDUES debarment was *not* removed
22) Add issuing rules so that an overdue item causes a temporary debarment
23) Check out an item to a patron and backdate the due date by a year
24) Return the item
25) Verify the SUSPENSION debarment was added to the patron
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
CheckReserves was using the CircControl system preference to determine what
patrons an item can fill a hold for. It should be using ReservesControlBranch
instead.
Test Plan:
1) Set ReservesControlBranch to "item's home library".
2) Create an item at Library A, place holds for it for patrons at
Library B, Library C, and Library A in that order,
for pickup at the patrons home library.
3) Make sure the holds policy for Library A is set to
Hold Policy = "From home library" and
Return Policy = "Item returns home".
Make sure the holds policies for the other libraries are set to
Hold Policy = "From any library".
4) Check the item in at Library C, the hold for the patron at Library B
should pop up, even though it's in violation of the circulation rules.
Don't click the confirm button!
5) Apply this patch, and reload the page,
now the hold listed should be for the last hold,
the hold for the patron at Library A, which is correct.
This patch adds the subroutine C4::Reserves::GetReservesControlBranch as
an equivilent to C4::Circulation::_GetCircControlBranch.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Fixed POD so that arguments and explanation match (C<$item>).
Also tested opac-reserves.pl for regressions.
Passes all tests, QA script, and Reserves.t.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
As QA followup on report 9722. Built on top of another followup report 10321.
Test plan:
Run the db revision included in the other patch.
Enable OpacHoldNotes. Check that you can add a hold note on opac-reserve.
Do you see it on opac-user and in staff on catalog detail of that biblio?
Do a grep on ShowHoldNotes on the Koha code: grep -i ignores case. You should
find three occurrences only in updatedatabase.pl (the old dbrev and this dbrev
renaming them). These are fine.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Based on work for report 9722.
This patch resolves a small display problem with the number of columns of the
table on opac-reserve.
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The option of adding a note is controlled by new pref OpacShowHoldNotes.
This development is part of a larger one (see umbrella report 9721).
Test plan:
1 Verify if new pref is disabled by default. Place a hold. You can't add a note.
2 Enable the pref. Place a hold and add a note. Check in staff if you can see
the note in Catalogue Detail/Holds tab.
3 Toggle SingleBranchmode, AllowHoldDateInFuture/OPACAllowHoldDateInFuture,
OPACShowHoldQueueDetails, or OPACItemHolds.
Check the display of columns when placing a hold from opac.
4 Place a few holds with notes from opac search results in one run (enable
DisplayMultiPlaceHold). Check results in staff again.
Remark: A few lines already refer to mandatory note reasons. This is handled
in a subsequent report. No reason to worry.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
The $anyholdable variable was set to 0 or 1. However, as it is set in
a loop, and future changes to the opac-reserve.pl script may require
knowing how many items the patron is going to place a hold on, it makes
more sense to treat $anyholdable as a counter. This follow up turns it
into one.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
opac-reserve.pl tries to check whether all selected titles in a
multiple-hold batch are unavailable to be placed on hold. However, the
logic is flawed in such a way that if the last item in the batch cannot
be placed on hold the script assumes none can be placed on hold.
This patch modifies the way the script tracks the "no titles available
for holds" variable in order to correct the error.
To test, place multiple holds by selecting titles from a list of search
results. Test three conditions:
- All titles are available to be placed on hold
You should see no onscreen warnings, and all titles should be
selectable on the place hold screen. A "Place hold" button should
appear at the bottom.
- Some titles can be placed on hold, some cannot
The titles which can be placed on hold should be selectable.
Titles which cannot be placed on hold should show a warning
message. A "Place hold" button should appear at the bottom.
- No titles can be placed on hold
"Sorry, none of these items can be placed on hold." should appear at
the top of the page. All titles should appear with warning messages.
There should be no "Place hold" button.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests and QA script pass.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This patch replace use of CGI::scroll_list() to show list of branches.
In two files, marc21_linking_section.pl and unimarc_field_4XX.pl,
the scrolling list is created but not used in the template file,
so the code is removed.
Also minor renaming/normalizing of variables.
To test:
1) Install with some branches, records and patrons
2.1) Select a record, click 'Place hold', select user,
there is a library pull-down next to 'Pickup at:',
list is ordered case sensitive
2.2) Go to Reports > Average loan time,
next to Library is a pull-down,
list without order
2.3) Go to Reports > Catalog by item type,
next to 'Select a library' is a pull-down,
list is ordered case sensitive
2.4) This is tricky, go to Reports home,
change last part of URL 'reports-home.pl' with
'manager.pl?report_name=issues_by_borrower_category'
(can't find a direct link), next to 'Select a library'
is a library pull-down,
list without order
2.5) Edit/Add a patron, on section 'Library management'
there is a library pull-down, case sensitive
2.6) OPAC, as logged user, make a suggestion or hold,
there is library pull-down, correct order
3) Apply the patch
4.1) Repeat 2.1), correctly ordered list
4.2) Repeat 2.2), correctly ordered list
4.3) Repeat 2.3), correctly ordered list
4.4) Repeat 2.4), correctly ordered list
4.5) This is a bit more work
There are 3 possible situations to test:
A) No branches, must show a message that are no
libraries defined
B) New patron, must show a correctly ordered
list of branches, current branch selected
C) Edit patron, must show a correctly ordered
list of branches, patron branch selected
4.6) Small changes on variable names, so retest 2.6)
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
- the dateformat value is send to all templates (from
C4::Auth::get_template_and_user)
- remove all assignment of dateformat in all .pl files
- the DHTMLcalendar_dateformat variable is unused
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Fixed conflicts:
- opac/sco/sco-main.pl
- reports/acquisitions_stats.pl
- tools/cleanborrowers.pl
All tests pass, perlcritic problems appeared in some files
before and after these patches were applied.
Checked sorting in following pages:
- acqui/addorderiso2709.tt - list of staged imports in acq
- acqui/histsearch.tt - sorting of dates in acq search result list
- acqui/invoices.tt - billing date in list of invoices in acq
- acqui/lateorders.tt - list of late orders in acq
- acqui/ordered.tt - ordered titles and estimated costs for a fund
- acqui/parcels.tt - receive shipment page
- acqui/spent.tt - received titles and actual costs for a fund
...
- serials-search.tt - subscription search result list
...
- opac/sco/sco-main.tt - due dates in list of checked out items
- reports/acquisitions-stats.tt - date searches, display of dates
- tools/cleanborrowers.tt
- tools.holidays.tt - different views of dates library is closed,
adding dates
Checked dates display according to system preference everywhere and
searching, entering dates etc. still worked as expected.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Added a system preference to turn on/off this feature.
By default the system allow the patron to place holds even if it is in his possession.
Script to place holds check if the system preference is off and if patron has at least one item to block holds.
Messages to say that are already in patron possession added to templates.
Method to check if patron has one issue from one record added to C4::Circulation
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests and perlcritic pass.
Tests done:
holds policy vs. circulation rules seemed to make the difference for me,
I am not totally sure why that is, but see no reason to fail this patch as
results are ok.
System preferences
- CircControlBranch = the library the item is from
- ReservesControlBranch = patron's home library
Circulation rules
- Library A - Holds policy: Books can not be put on hold.
- Library B - Holds policy: Books can be put on hold. (no special setting needed)
Catalog data
- A record with an item for library B, itemtype Books.
Test without patch:
1) Patron A (home library A) places a hold in OPAC on an item from library B.
Should be: hold is NOT allowed.
Before patch: hold IS allowed.
After patch: hold is NOT allowed.
OK
2) ReserveControlbranch = item's home library
Patron A (home library A) places a hold in OPAC on an item from library B.
Should be: hold is allowed.
Before patch: hold is allowed.
After patch: hold is allowed.
OK
3) ReservesControlBranch = patron's home library
Circulation rules: Remove hold policy for library B.
Library A: no holds allowed for books using 'Holds allowed (count)' = 0
Library B: 5 holds allowed for books using 'Holds allowed (count)' = 5
Patron A (home library A) places a hold in OPAC on an item from library B.
Should be: hold is NOT allowed
Before patch: hold is NOT allowed
After patch: hold is NOT allowed
OK
4) ReserveControlbranch = item's home library
Should be: hold is allowed
Before patch: hold is allowed
After patch: hold is allowed
OK
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
The check that the max number of reserves has
not been reached needs to take account of the fact
that we may have added enouch reserves to
reach the limit while this script is running.
Add a check against the incrementing count
The variable canreserve was only used when looping
through multiple holds but was not being
reinitialized on every iteration
make variable local to loop it is used in and
initialize to zero
Have used perltidy to correct the indention of
the while loop as it was misleading to the reader
Some numeric comparisons were using a string operator
fix them before strange bugs manifest themselves
The loophole manifests thus:
borrowers are only allowed Y holds.
If holds are done individually, it is
obeying that law i.e. X has held Y separate books –
when I tried to do a 6th
book it told me that I could not place a hold.
However, if a borrower checks the catalogue,
gets the intial list up and clicks items on the “results”
box and then clicks “place hold” they can hold more than Y
items Please enter the commit message for your changes. Lines starting
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Calculation of rank was being skipped based on display
option but it is used in calculating the rank passed
to AddReserve resulting in reserves being created with
null priorities causing them to be skipped in subsequent
processing
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
1 more to go... :)
opac/changelanguage.pl: Code before strictures are enabled at line 24, column 1.
See page 429 of PBP. (Severity: 5)
Note: Rebased on master 06/09/2012 by jcamins
Signed-off-by: Joy Nelson <joy@bywatersolutions.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
New syspref is Choice, options being:
- None
- Priority only
- Holds number only
- Holds number and priority
Show holds count on OPAC detail
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
* fixed documentation in C4/Auth_with_ldap.pm
* updated ILSDI/Utility.pm to work with debarred being a date
* updated Members.pm/patronflags to work with debarred being a date (copy/paste of BibLibre code that had not been backported)
* fixed opac-reserve to check correctly for debarred status
I also have removed a duplicate line on circulation.pl when the patron was restricted = the information was displayed twice
Display links to parent biblios, show linked items in holdings, allow holds on
linked items. This uses MARC to maintain relationships.
Sponsored by the Mississippi Department of Archives and History and RapidRadio
Solution. Originally developed by Savitra Sirohi and Amit Gupta at OSSLabs, with
UNIMARC support added by Zeno Tajoli. Commits squashed and merge conflicts
resolved by Chris Cormack from Catalyst. Respect for NORMARC and some small
framework portability fixes made by Jared Camins-Esakov of C & P Bibliography
Services.
IMPORTANT NOTE: A bug in the 773 coding for MARC21 was corrected from the
original OSS Labs code. The 773s generated by the pre-release code did not have
the first indicator set to '0', which means that they were not supposed to
display. Going forward, the first indicator will be set correctly, but existing
records created with this code will no longer appear (they appeared before only
due to another bug). To correct this, you could globally (or, to make sure you
only modify records created with the Analytics tool, for records with 773$0)
change the first indicator of the 773 from blank to '0'.
== Background ==
An analytic record for an item is a more detailed, monographic biblio for an
item attached to a serial record . This is often used for special issues of a
journal that are released as books on their own (assigned an ISBN, as well as an
ISSN/volume/issue). It is important for researchers to be able to search for
these items both as issues of the serial, and as monographs. It is equally
important for the library to not have duplicate item records for the item in
question to have to keep synchronized.
== Establishing relationships ==
Analytical records are connected to items belonging to parent or host
bibliographic records. This can be accomplished by:
* From an analytical bibliographic record linking to an host item by providing
the item barcode as input
* From a host item by using option "analyze", this creates a new empty
bibliographic record with field 773 (MARC21) populated
* Running a new CLI script that establishes a relationship between the
analytical record and the host item identified by the barcode in the
analytical record's 773$o (MARC21)
== Connecting Records ==
The relationships are maintained in the MARC records, we have not used database
tables at all.
== MARC Representation ==
In MARC21/NORMARC we have used:
* 773$9 to store the Koha item number of the host item
* 773$0 to store the Koha biblio number of the host bibliographic record
The above fields are used to display the relationships in various screens in the
OPAC and the staff interface. Additionally, when populating field 773 with host
item's details, we have used following MARC 21 mapping:
* 'a' <= 100/110/111 $a (author main)
* 'b' <= 250$a (edition)
* 'd' <= 260$a, 260$b, 260$c (place, publisher, year)
* 'o' <= barcode
* 't' <= 245$a (title)
* 'w' <= (003)001 --> if no 001 is available, we can populate biblionumber
* 'x' <= 022$a (issn)
* 'z' <= 020$a (isbn)
In UNIMARC, this code uses:
* 461$9 to store the Koha item number of the host item
* 461$0 to store the Koha biblio number of the host bibliographic record
When populating field 461 in UNIMARC, the following mapping is used:
* 't' <= 200$a (title)
== Treatment of Holds ==
A key requirement was to allow holds to be placed on host items from the
analytical record. We have accomplished this by allowing holds on specific
copies only. Biblio level holds are not allowed. This ensures that holds are
placed on specific items that are relevant to the analytical record.
== Deleting host items with linked analytical records ==
As we have not used database tables to maintain relationships, we had to use
search to find out if any linked analytical records are present. If 1 or more
analytical are present, we do not allow deletion of items. This is similar to
what we see when we try to delete authority records.
== Importing analytical records ==
Analytical records can be imported using bulkmarcimport or the GUI tools. The
new CLI script can be executed after the import to establish relationships with
host items. The script will establish relationships using the host item's
barcode, the barcode must be present in 773$o of the analytical record.
== What if there are two or more copies of the host item? ==
The current design will require that there be two host (773) fields, one for
each copy.
== What if there is no barcode available for the host item? ==
It is still possible to establish a relationship, by populating 773$9 with the
host's item number. However the CLI script uses barcode in 773$o to establish
relationships so it won't work where barcodes are unavailable. Also from an
analytical record, it is possible to establish a relationship to a host item by
providing the barcode as input, this option will not be available as well.
Commits that added the following features were squashed by Chris Cormack (this
is not a list of every commit):
* Display links to host records from biblio detail screens
* Support for UNIMARC, respecting the system preference 'marcflavor'
* Support holds from the OPAC
* Ability to link to items belong to host records from a analytical record
* Display items belonging to host records in the moredetail page
* Ability to edit items belonging to host records, also ability to delink from
them
* Move get host items code into a C4 routine, also calling the new routine in
related perl scripts
* Move host field population to a C4 routine, all changes in pl files to call
new routine
* Allow only specific copy holds for analytical records plus changes to use new
C4 routines
* Support for holds on items linked via host records
* Storing bibnumber and itemnumber in subfields 0 and 9, plus other mapping
changes
* New command line script that establishes relationships between analytical
records and host items and bibs. The script looks for host field (MARC21 773)
in records, and based on barcode in subfield 'o' populates host bibnumber in
subfield '0' and host itemnumber in subfield '9'. The script can be run after
an import of analytical records, it can also be run in the crontab to maintain
the relationships
* Ability to create analytical records from items, to view linked analytics, and
prevent deletion of items that have linked analytics
* New template for catalogue/detail.pl (NOTE: not a new template file, just a
new way of displaying analytics), template displays linked analytics and
allows creation of analytical records
* New zebra index for item number in host fields. This index will be used to
display links to analytical records from host records
* Display title of host record instead of the phrase host record
* Using detail.tmpl for analytics tab instead of a new template file
* Improved qualification info prepration in Prephostmarcfield
* Check for linked analytics before deleting item
* Display link to host record and more meaningful anchor text for edit item link
* Analytical record: Unimarc index in record.abs and help in
create_analytical_rel.pl
* Adding a sys pref that controls display of options to create analytical
relationships
* Add host entry in XSLT stylesheet in staff item detail
* Added host record support to OPAC detail XSLT
* Adding 773$0 and 773$9 to all frameworks
* Adding 773 subfields 0 and 9 to default marc framework via updatedatabase.pl
* Display create analytics and used in links in catalog detail
* Fixed problem where analytical records not showing in OPAC search results
because GetMarcBiblio now needs a flag to add item records
* Fixed problem where analytics count was set to 1 for all records, not just
those with analytics
* Fixed catalogue detail page not to show analytics counts if count is 0
Conflicts:
installer/data/mysql/updatedatabase.pl
koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/addbiblio.tt
kohaversion.pl
Co-author: Savitra Sirohi <savitra.sirohi@osslabs.biz>
Co-author: Zeno Tajoli <tajoli@cilea.it>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Ian Walls <ian.walls@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
If a user is placing a reserve on the OPAC, this'll let them know that
it's going to cost them.
Author: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Edits by Owen:
- More variable scope corrections
- Minor markup and style tweak
- Table column span correction
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
- Item level holds can be placed and hold saved
- Table and layout are ok now
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Previous commit modified checks for the item-level_itypes preference
to look for a different variable name but didn't update where that
variable is set in Auth.pm.
Other scripts perform a direct check of item-level_itypes and must
continue to use the name of the variable in the database.
Signed-off-by: Ian Walls <ian.walls@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Done within opac and intranet templates, still needs to be done for corresponding scripts.
Signed-off-by: Colin Campbell <colin.campbell@ptfs-europe.com>
- Hiding form controls for titles which can't be placed on hold
- Highlighting hold blocked message for better visibility
- Showing table of blocked holds even if none can be placed on
hold: hiding the table hides the messages explaining why
titles can't be placed on hold
- Removing an unused line from the script which was leaving errors
in the error log
- Consolidating error messages into one box which were displaying
in two.
- Correcting link to unused opac-userdetails.pl
Signed-off-by: Nicole Engard <nengard@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
* export C4::Reserves::CancelExpiredReserves
* rename misc/cronjobs/cancel_expired_reserves.pl
to misc/cronjobs/holds/cancel_expired_holds.pl
* added cancel_expired_holds.pl to example crontab
* fix staff crash if AllowHoldDateInFuture is on
* expirationdate is now nullable instead of relying
on 0000-00-00
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
This is a much improved re-implementation of the reserves updates from dev_week.
Less new code has been added, and more existing functions are used instead of adding new ones.
The 'Lock Hold' function has been removed due to it not working as intended.
[RM note for documentation: this adds the following features:
* ability to specify an expiration date for a hold request
when placing it via the staff interface or OPAC
* daily batch job to cancel expired holds
* nice interface to change the priority of hold
requests for a bib in the staff interface]
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
When AllowOnShelfHolds is enabled, but maxreserves is NULL, attempting to reserve
an item results in a basically blank page being returned with no error message.
This patch adds a check to see if the check for maxreserves has returned a value and
bypasses the application of it if it has not.
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
Adding finedays and reservesallowed and renewalsallowed management in smart rules
Adding Clone Rules
Adding CanBookBeReserved and CanItemBeReserved in C4::Reserves
Manage Reservesallowed in opac and staff interface
Manage renewalsallowed in C4/Circulation.pm
Update Database follow
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
This adds to the interface and code the ability to set the reserve date when
requesting a hold.
Resubmit. Sorry, I formatted it from the wrong branch.
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
Removed irrelevant and unused variables dealing with branches.
Also pulled default branch from userenv when not specified as a param.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
Updated the results, cart, and shelf pages to include a button
or link to initiate a hold request based on checked items.
Updated the request CGI scripts to handle multiple biblio items.
Updated the reserve confirmation page to display multiple items,
with an optional list of copies for each one.
Turned on warnings in opac/opac-reserve.pl and fixed resulting
warnings.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
* use item branch instead of patron's branch to
look up the applicable hold policies - this makes
requesting in the OPAC consistent with the intranet.
* when generating pick list using build_holds_queue.pl, only match items
to patrons if request is allowed.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
This adds holds policy creation support to smart rules and read support to
C4/Circulation.pm, and the two reservation pages. It also adds a system
preference, AllowHoldPolicyOverride, to control whether the staff can override
these policies.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
Signed-off-by: Daniel Sweeney <daniel.sweeney@liblime.com>
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
This patch removes some superfluous logic left over from early Koha
when a multi-step holds process allowed you to limit your choices to
specific biblioitems.itemtype values. Code previously required a value
in biblioitems.itemtype in order to place hold.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
This adds a new function, getitemtypeimagelocation, that returns the image
unmodified for absolute urls and returns the proper intranet or opac path
otherwise. It also updates all of the relevant files to use that function.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
Changed so that the presence of an on-order item (items.notforloan =- -1)
permits a title-level hold request to be made. Prior to this patch,
if all of the items linked to the bib were on-order, no title-level
request was permitted.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
GetMemberDetails() returns only one hashref now,
not two. In all cases where the caller was
expecting two output values, the $flags return
was ignored anyway.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
Fixed rules for determining whether an item is
available for an item-level hold request. Create a
new function in C4::Reserves, IsAvailableForItemRequest(),
that checks whether an item is potentially available for
an item-level hold request.
An item is considered available if:
* it is not lost AND,
* it is not marked not for loan AND,
* it is not withdrawn AND,
* it is not damaged (unless the AllowHoldsOnDamagedItems syspref is ON), AND
* it is not on loan (unless the AllowOnShelfHolds syspref is ON)
Preventing a hold request on withdrawn items is bug 1739, as is
the new preference on whether to allow holds on damaged items.
Removing the condition that an item cannot be requested if
it has already been requested by another patron is the topic of bug 1710.
Note that this patch does not change the behavior where if
independent branches is on and the canreservefromotherbranches
syspref is off, a staff operator is prevented from placing
an item-level hold request on an item from a different branch.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
But that is a separate bug from whether they display or not.
Also added basic error handling if biblionumber is not received, or
if biblionumber is bad, since that otherwise crashes the page.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
The new tables have the same structure and constraints
as the tables they archive with the following exceptions:
* borrowernumber and biblionumber in old_reserves can be
NULL
* the FK constraints (e.g., for itemnumber) on old_reserves
set the child column to NULL if the parent row is deleted
instead of deleting the child row.
* there is no FK constraint on old_issues.branchcode, allowing
a branch to be deleted without changing archived requests.
Some miscellaneous cleanup was done as part of this patch:
* GetMemberIssuesAndFines (C4::Members) now uses bind variables
* fixed POD for GetMemberIssuesAndFines
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
