Line from 16.11 log:
Use of uninitialized value within @itemnumber in string ne at /usr/share/koha/prodclone/reserve/modrequest.pl line 70.
Test plan:
Read the change. Not 100% identical (numeric zero) but should be enough.
This line is probably not needed at all.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test plan:
1) Enable the CheckPrevCheckout and DisplayMultiPlaceHold system preferences
2) Have a patron with some checkouts history
3) Try to place hold on one of titles from history for this patron
4) You should see an information at the top of confirm request page, but
you still should be able to place a hold
5) Try this with multiple titles - one or more of them should be from
history
6) You should see this information in "Information" column
7) There is also new column placed at the beggining with checkbox, you
could uncheck it for titles you do not want to place a hold on it
8) Confirm the hold is placed only on checked titles
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Bin Wen <bin.wen@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch corrects a missing id on the holds_to_place field and adds code to disable the box when an item is checked
Additionally script login now places a single hold if an itemnumebr is passed and checks for holdability of the specific item
To test:
1 - Allow multiple holds per record in circ rules
2 - In staff client, go to place a hold on a record
3 - Select a patron
4 - Increase the number of holds
5 - Then select a specific item to hold
6 - Patron now has multiple holds on a single item
7 - Apply patch
8 - Repeat, notice that count is disabled when item checked
9 - Confirm count is enabled when 'Hold next available item' is checked
10 - Set number to more than 1
11 - Check an item and submit
12 - Confirm only one item is reserved
13 - Hit the script directly (with valid info):
http://localhost:8081/cgi-bin/koha/reserve/placerequest.pl?biblionumber=1&checkitem=1&holds_to_place_count=2&borrowernumber=5
14 - Confirm only one hold is placed
15 - Confirm multiple hits of the url do not generate further holds
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
To test:
1 - Set an All/All/All rule with reserves limited 2 to
2 - Search in the staff side
3 - Select all records (or more than 2) from the results
4 - Click 'Place hold'
5 - Find a patron, place holds
6 - You get more holds than you should
7 - Delete those holds
8 - Apply patch
9 - Search and select more than 2 records
10 - Find patron, place holds
11 - Only 2 holds are placed
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Branch transfer limits are respected for placing holds in the OPAC but nowhere else. This should be remedied.
Test Plan:
1) Set up a branch transfer limit from Library A to Library B
2) Verify you cannot set up a hold for an item from Library A for pickup at Library B from the staff interface ( without overriding )
3) Verify you cannot place that hold via ILS-DI
4) Verify you cannot place that hold via SIP
4) Verify a forced hold from Library A to Library B will not show up in the holds queue
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Note: This is here for information purpose, feel free to test it if you
wan to play with it.
TODO: C4::Reserves::_get_itype is not longer in use
No more GetItem must be returned by:
git grep GetItem|grep -v GetItemsAvailableToFillHoldRequestsForBib|grep
-v GetItemsForInventory|grep -v GetItemsInfo|grep -v
GetItemsLocationInfo|grep -v GetItemsInCollection|grep -v
GetItemCourseReservesInfo|grep -v GetItemnumbersFromOrder|grep -v
GetItemSearchField|grep -v GetItemTypesCategorized|grep -v
GetItemNumbersFromImportBatch|cut -d':' -f1|sort|uniq
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The changes caused by the patches for bug 11512 have broken existing
workflows for many libraries and are widely considered to be a bad move.
We should revert this behavior.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Rhonda Kuiper <kuiper@roundrocktexas.gov>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch disables the dropdown for found holds, and adds a new button
to revert the waiting status, setting the hold to priority 1
Additionally we remove some changes from 19469 and update the JS to skip
found holds when updating priority
To test:
1 - Find a record with multiple items
2 - Place 4 holds (or more)
3 - Capture one ohld as waiting, one as in transit
4 - View the holds on the record - switch the last to priority one
5 - Waiting and transit statuses get confused
6 - Apply patch
7 - Observe dropdown is now disabled for waiting holds
8 - Confirm other holds operate as expected
9 - Confirm 'Revert found status' resets hold
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 21608: (follow-up) Use RevertWaitingStatus and do not alter _FixPriority
[EDIT]
Completely removed the changes to Reserves.pm by adding module prefix in
the request.pl script.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch was generated using codespell
Test plan:
Read through changes and confirm they make sense
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
https://bugs.koha-community.org/show_bug.cgi?id=21706
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch adds a new collection column to the item table when selecting
a specific item for a hold. The column will only appear if at least
one item has a collection set.
To test, in staff:
- Place a specific hold on
- a record with one or more items with collections
- a record with one or more items without collections
- Verify the collections display correctly when they exist
- Verify the table still works as expected
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The subscriptionsnumber is required in biblio-view-menu.inc to display
the Subscription(s) tab. In detail.pl, if you click any of
Labeled MARC (you need to set the syspref viewLabeledMARC)
Hold(s)
Article requests
Checkout history
Modification log
Rota (you need to set the syspref StockRotation)
you lose the Subscription(s) tab.
This patch fixes the display by having each feature script generate that
value to be passed to the UI. I keep this separated from the first patch
since it's not exactly the same issue, and the solution might not
please.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
It is possible to set up circulation rules to limit trapping of holds by pickup library and itemtype.
To make it easier to understand which holds will be trapped in a given circumstance,
it would be nice if we could optionally group holds by pickup library and/or itemtype.
Test Plan:
1) Apply this patch set
2) Run updatedatabase.pl
3) Enable AllowHoldItemTypeSelection
4) Pick a record and create holds with various pickup libraries and itemtype combinations
5) Enable HoldsSplitQueueNumbering
6) Try the different combinations of HoldsSplitQueue
7) Ensure the hold "arrows" move the items correctly
* Up and down arrows should move hold above or below the adjacent hold within a hold fieldset
* Top and borrom arrows should move hold to the top or bottom within a hold fieldset
Sponsored-by: Stockholm University Library
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Followed test plan, patch worked as described. Also passed QA test tool
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Victor Grousset <victor.grousset@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Currently in Koha, if you choose to force a hold from the staff side that would contravened the current issuing rules, that hold will never be filled, as it is always skipped over by CheckReserves.
This patch disallows overrideing except for tooManyReserves which are the only overridden holds that will be trapped.
Test Plan:
1) Apply this patch
2) Attempt to override hold placement, only placements where the patron has too many holds already should be allowed
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We lost the ability to place multiple holds when we are searching for
patrons. The multi_holds parameter is lost and not handled correctly in
the template.
Test plan:
- Make sure you can place multiple holds for a patron you will search for
- Same for simple hold
TODO the multiple holds view should not be displayed if only 1 record
has been selected from the search result.
Signed-off-by: claude brayer <claude.brayer@cea.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch fixes very weird behaviours introduced by
commit 0ab22e1c7c
Bug 18789: Send Koha::Patron object to the templates
The patron variable was only set when no action was defined.
This patch restores the feature the easiest way possible (less changes)
even if it is not the best one.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This subroutine is only used once and can be replaced easily with a
Koha::Biblioitems->search call
Test plan:
Test this on top of bug 19941 and confirm that the correct item types
are displayed
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The GetMemberAccountRecords may be a perf killer, it retrieves all the
account lines of a patron and then the related item and biblio
information.
Most of the time we only want to know how much the patron owns to the
library (sum of amountoutstanding). We already have this information in
Koha::Patron->account->balance.
This patch replaces the occurrences of this subroutine by fetching only
the information we need, either the balance, the detail, or both.
It removes the formatting done in the module, to use the TT plugin
'Price' instead.
There is a very weird and error-prone behavior/feature in
GetMemberAccountBalance (FIXME): as the accountlines.accounttype is a
varchar(5), the value of the authorised value used for the
ManInvInNoissuesCharge pref (category MANUAL_INV) is truncated to the 5
first characters. That could lead to unexpected behaviors.
On the way, this patchset also replace the GetMemberAccountBalance
subroutine, which returns the balance, the non issues charges and the
other charges. We only need to have the balance and the non issues
charges to calcul the third one.
Test plan:
Add several fees for a patron and play with HoldsInNoissuesCharge,
RentalsInNoissuesCharge and ManInvInNoissuesCharge.
The information (biblio and item info, as well as the account line) must
be correctly displayed on the different screens: 'Fines' module, fine
slips, circulation module
Note that this patchset could introduce regression on price formatting,
but will be easy to fix using the TT plugin.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In order to simplify and make uniform the code, the controller scripts send
a Koha::Patron object to the templates instead of all attributes of a patron.
That will make the code much more easier to maintain and will be less
error-prone.
The variable "patron" sent to the templates is supposed to represent the
patron the librarian is editing the detail.
In the members module and some scripts of the circulation module, the
patron's detail are sent one by one to the template. That leads to
frustration from developpers (making sure everything is passed from all
scripts) and to regression (we got tone of bugs in the last year because
of this way to do).
With this patch set it will be easy access patron's detail, passing only
1 variable from the controllers.
Test plan:
Play with the patron and circulation module and make sur the detail of
the patron you are editing/seeing info are correctly displayed.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There is already a HidePatronName syspref to hide patron's information
on bibliographic
record detail pages and the hold list.
Test plan:
With the HidePatronName enabled, make sure the patron's information are
hidden from
the catalogue and hold list pages. If the logged in user is not allowed
to see the
patron's info, no link and no cardnumber will be displayed
With he HidePatronName disabled, make sure the patron's information are
displayed
if the logged in user is allowed to see the patron's info.
Technical note:
This patch improves the existing patron-title.inc include file to
display patron's
information. Using it everywhere patron's details are displayed will
permit to
homogenise the way they are displayed. The file takes now a patron
object (what
should be, in the future, the only way to use it), that way we can call
the new
method on it to know if patron's information can be shown by the logged
in used.
NOTE: I am not sure this syspref makes sense anymore. Should not we
remove it?
Signed-off-by: Signed-off-by: Jon McGowan <jon.mcgowan@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
Check the following files that use strict; use warnings; doesn't exist
and use Modern::Perl; is written instead.
modrequest.pl
modrequest_suspendall.pl
placerequest.pl
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patchset move The OPACItemHoldsAllowed logic
(issuingrules.opacitemholds) to a new class method of
Koha::IssuingRules: get_opacitemholds_policy
On the way, this patch will certainly fix the same problem as bug
19298 with onshelfholds.
Test plan:
Make sure the opacitemholds policy is correct when placing a hold at the
OPAC or the staff interface.
Followed test plan which worked as described
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test Plan:
1) Enable AllowHoldPolicyOverride
2) Enable AllowHoldItemTypeSelection
3) Create a situation where adding a hold for a patron would trigger a tooManyReserves
warning.
4) Note the itemtype pulldown is empty
5) Apply this patch
6) Reload the page
7) Itemtype pulldown should have values
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug caused by
commit bc39f0392b
Bug 14695 - Add ability to place multiple item holds on a given record per patron
Test Plan:
1) Set AllowHoldsOnPatronsPossessions to "Don't"
2) Check out an item to a patron
3) Place a hold on that item for the same patron
4) Note you are allowed to with no alert
5) Delete the hold
6) Apply this patch
7) Place a hold on that item for the same patron
8) Note you recieve an alert now
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a new Koha::Hold->cancel method and replaces the calls
to C4::Reserves::CancelReserve with it.
Test plan:
- Add and cancel holds
- Change priority of holds
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This subroutine is only used once and can easily be replaced with
Koha::Patron->holds->count
Test plan:
- Set maxreserves=5
- Place 3 holds for a given patron
- Place again 3 holds for this patron
3+3 > 5 => The holds must not be placed
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Most of the time C4::Biblio::GetBiblioData is used to retrieve the title
and/or the author of a bibliographic record.
This patch replaces the easy occurrences of GetBiblioData, the ones
where the 2 joins are needed, but only data from biblio and biblioitems
table are.
Test plan:
It will be hard to test everything, I'd suggest a QAer to review this
patch and confirm that the difference occurrences of GetBiblioData have
been correctly replaced by calling Koha::Biblios->find or
$biblio->bibioitem
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This script is really ugly and need to be rewritten completely to
separate the different action.
$patron is not always defined, we need to take it into account.
Note that this patch is mainly indentation changes.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
GetMember returned a patron given a borrowernumber, cardnumber or
userid.
All of these 3 attributes are defined as a unique key at the DB level
and so we can use Koha::Patrons->find to replace this subroutine.
Additionaly GetMember set category_type and description.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
C4::Circulation::GetItemIssue returned all the issue and item
informations for a given issue. Moveover it also did some date
manipulations. Most of the time this subroutine was called, there
additional information were useless as the caller usually just needed
the basic issue's infos 'from the issue table).
This first patch updates the simple calls, ie. the ones that just need
the issue's infomations.
Test plan:
The following operations should success:
- transfer a book
- create a rule for on-site checkouts and confirm that a patron cannot
check more items out that it's defined in the rule.
- Renew an issue using ILSDI
- Using SIP confirm that you are able to see your issues
Followed test plan, works as expected
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
"$itemnumbers_of_biblioitem" is declared but not used at line 314,
column 5. Unused variables clutter code and make it harder to read.
(Severity: 3)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
At this point this subroutine is only used once, from reserve/request.pl.
Since we already have the items, it's easy to populate the different
hashes as the rest of the code is expecting it.
Test plan:
You need to create analytical record relationships (
EasyAnalyticalRecords needs to be set). Link an item to a biblio using
the 'Edit > Link to host item' menu from the biblio detail page.
From the staff interface place a hold on the biblio. You should see the
items from the biblio and the one you just linked
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
The code from scripts and subroutines using this subroutine was not very
elegant. Most of the time the code was unnecessarily complex.
This patch removes this subroutine and adapt the code to use
Koha::Items instead.
1. C4::Items::get_hostitemnumbers_of
I did not understand why the code was so complicated, it seems that we
only want to know if a given item has a given biblionumber
2. cataloguing/merge.pl
We want to retrieve the itemnumber for a given biblio.
We could also have done that with:
Koha::Biblios->find( $biblionumber )->items;
3. labels/label-item-search.pl
We want to loop over the items for a given biblio, no need to use
get_itemnumbers_of and GetItemInfosOf.
We just need to use:
Koha::Items->search({ biblionumber => $biblionumber })
4. reserve/request.pl
We want to retrieve the itemnumbers of the biblio's items
We could also have done that with:
Koha::Biblios->find( $biblionumber )->items->get_column('itemnumber');
Test plan:
1.You need to create analytical record relationships (
EasyAnalyticalRecords needs to be set). Link an item to a biblio using
the 'Edit > Link to host item' menu from the biblio detail page.
From the staff interface place a hold on the biblio. You should see the
items from the biblio and the one you just linked
2. Merge two bibliographic records (with items), the resulting record
should contain items from both original records
3. Create a new label batch, edit it.
Add items to this batch ('Add items' button).
Fill the input with a barcode.
You should see all the items of a biblio.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: sonia BOUIS <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Updating to use they/them and skipping the ones changed to it
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comments throughout the Koha codebase assume that
all librarians or borrowers are male by using the
pronoun 'he' universally. This patch changes to
'he or she' / 'him or hers'.
Testing plan:
- ensuring modifying tests still pass:
+ C4/SIP/t/06patron_enable.t
+ t/db_dependent/Circulation.t
+ t/db_dependent/Koha/Patrons.t
+ t/db_dependent/Reserves.t
Sponsored-By: California College of the Arts
No code changes detected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Lari Taskula <lari.taskula@jns.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
On the same way of Koha::Biblio->get_holds,
Koha::Biblio->get_holds_placed_before_today and Koha::Patron->get_holds,
this new subroutin will permit to retrieve the holds placed on a
specific item.
Note that at the moment we do not need a Koha::Item->get_holds method:
we do not want to display future holds placed in the future.
Test plan:
I would suggest to test this patch with patches from bug 17736 and bug 17738,
to place different kind of holds (biblio and item level, future and
past).
Then do a whole workflow to detect bug, view a record, delete record,
order, place a hold on an item which has been ordered, etc.
The hold's informations should always be the same without or without
these patches.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch is more a bugfix than a refactoring.
Indeed the C4::Koha::get_notforloan_label_of behaviors were buggy:
1/ It does not display the opac description at the OPAC, but always the
staff description
2/ It does not care of the framework of the biblio, but retrieve the
first row of the marc_subfield_structure mapped with items.notforloan
These 2 bugs can easily be fixed using the
Koha::AuthorisedValues->search_by_koha_field
Steps to recreate the issues:
- Create 2 authorised value categories for not for loan (NFL1 and NFL2)
with the same values. Define a different description for the OPAC.
- Define link 952$7 to NFL1 for the default framework and to NFL2 for
the BK framework
- Create 2 bibliographic records (B1 using NFL1 and B2 using NFL2) with
2 items each (1 item should have a not for loan value)
- Go to the "Place a hold" view for this record.
- In the item list, you should see the not for loan value
=> The staff description of NFL1 will always be used, even for the OPAC
Test plan:
- Recreate the issues without this patchset
- Apply this patchset
- Recreate the steps to recreate the issues
=> The staff description of NFL2 should be displayed for the B2 item
=> The opac description of NFL2 should be displayed for the B2 item at
the OPAC
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The subroutine C4::Members::GetHideLostItemsPreference can easily be
replaced with Koha::Patron->find(42)->category->hidelostitems
Test plan:
Create 2 patron categories, 1 with "Lost items in staff client" set to
"shown" and another one to "Hidden by default"
Create 2 patrons using them
On the result search page, the detail page of a record, the item list
page and the page to place a hold, make sure the lost items are
shown/hidden as expected
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This fix the following bug:
If you select 2 in "Holds to place (count)" and finally
check an item, so you get 2 holds for the same item.
Signed-off-by: Jason M. Burds <JBurds@dubuque.lib.ia.us>
Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>
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>
Test plan:
Hit
/cgi-bin/koha/reserve/request.pl?biblionumber=1"><script type="text/javascript">alert("XSS")</script>
=> Without this patch you will see the alert
=> With this patch, no more alert
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@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>
It is not used since bug 11703
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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>
This patch replaces the occurrences of
my @foo = $cgi->param('foo');
with
my @foo = $cgi->multi_param('foo');
perl -p -i -e
's/^(\s*my\s*@\w+\s*=\s*)\$(cgi|input|query)\->param\(/$1\$$2\->multi_param\(/xms'
**/*.pl
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@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>
C4::Branch::GetBranchDetail retrieved library infos, it could be easily
replaced with Koha::Libraries->find
When this change needs other big changes, the unblessed method is
called, to manipulate a hashref (as before) instead of a Koha::Library
object (for instance when $library is sent to GetPreparedLetter).
Test plan:
1/ Print a basket group, the library names should be correctly
displayed.
2/ Enable emailLibrarianWhenHoldIsPlaced and place a hold, a HOLDPLACED
notice will be generated (focus on the library name)
3/ Edit a patron and change his/her library
4/ Generate the advanced notices (misc/cronjobs/advance_notices.pl) and
have a look at the generated notices
5/ Same of overdues notices
6/ Set IndependentBranches and use a non superlibrarian user to place a
hold. The "pickup at" should be correctly filled.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
A hold in transit will simply appear as an unfilled hold!
Test Plan:
1) Place a hold for pickup at a different location
2) Capture that hold for a patron
3) Note you do not see the in transit status on request.pl
4) Apply this patch
5) Refresh the page
6) The hold should now show as in transit!
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
To Test-
chek that in line 4 "writen" has been changed to "written"
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
writen ==> written
To Test-
check that in line 4 of this file "writin" has been corrected to "written"
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
The holds table should show the waiting date for a hold in s similar
manner to the way it does on catalogue/detail.pl In addition, if the
ReservesMaxPickUpDelay syspref is set, we should display the date
when the waiting hold expires.
Test Plan:
1) Apply this patch
2) Set ReservesMaxPickUpDelay to 7
3) Find a waiting hold
4) Browse to reserve/request.pl for that record
5) Notice the "Item waiting" message now has "since <waitingdate>"
6) Notice the expiration field now has the date of <waitingdate> + 7 days
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Cathi Wiggins <CWIGGINS@ci.arcadia.ca.us>
Signed-off-by: Megan Wianecki <mwianecki@mplmain.mtpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
This patch ensures that the global maxreserves preference is enforced
when staff members place hold requests.
For example:
Create 3 items to place holds on. Set the circulation rule to allow 50
holds for all items. Set maxreserves to 2. Place a hold on 3 different
items. On the third item, it will give a warning, but you can still
place the hold. Despite what the circulation rule is set for (which is
only a specific case rule), maxreserves is a global rule and
should stop this from happening, not just give a warning.
Test Plan:
1) Reproduce the bug by following the steps above
2) Verify the bug exists
3) Apply this patch
4) Verify the librarian cannot place the hold now
5) Enable AllowHoldPolicyOverride
6) Verify the librarian can forcefully place the hold
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12197: (follow-up) rename variable for greater clarity
"maxreserves" was referring both to the system preference and to the
condition of having exceeded the number of hold requests allowed.
This patch renames a variable to remove the ambguity.
Test plan:
* Same as the main patch.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Librarians should be warned that a patron is restricted when placing
holds, as they are warned that a patron's acount has expired.
Test Plan:
1) Apply this patch
2) Add a restriction for a patron
3) Attempt to place a hold for that patron
4) Note the notice at the top notifying you that the patron is restricted
Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If a patron owes more than the system preference maxoutstanding in fees
and fines, the patron will be unable to place holds via the opac.
However, a librarian placing a hold for a patron is not even warned!
Test Plan:
1) Apply this patch
2) Set maxoutstanding to 1.00
3) Find a patron owing more than 1.00
4) Attempt to place a hold
5) Note the warning that the patron owes money
Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This bug removes deprecated C4::Dates from reserve/request.pl
To test:
- Apply patch
- In staff client, search a biblio and try to put a hold for a borrower (Home > Catalog > [Some Biblio] > Place a hold to [Some biblio])
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1) Create a new record in Cataloguing
2) When done, instead of adding an item to the record, click on the Holds tab in the left nav
3) Notice warns
4) Apply patch and refresh page
5) Click on Holds tab again
6) Notice warns are gone and page still works
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Warns disappear; note that the display of the error message is still ugly.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
In the staff client we had still some remains referring to the
constraint types.
Also touched one comment line from SIP.
Test plan:
Add a hold in the staff client.
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>
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>
The due dates should be displayed as due dates :)
i.e not displayed with 23:59
On the way, this patch fixes the sort on the info column.
The column is now sorted using the due dates
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
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>
Squashed this rogue variable initialization
Test plan:
1/ Place a hold at a biblio level (on the next available item)
2/ Without this patch you get
placerequest.pl: Use of uninitialized value $checkitem in string ne at /home/koha/src/reserve/placerequest.pl line 75.
placerequest.pl: Use of uninitialized value $checkitem in string ne at /home/koha/src/reserve/placerequest.pl line 101.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Fixed a tab.
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>
In the case where only 1 result is returned by the search, the
borrowernumber should be passed correctly.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Important note: This will modify the UI.
The patron list will now be displayed in a table (instead of a select).
Test plan:
1/ Place a hold on a record
2/ Search for a patron
3/ Select a patron and submit
4/ The hold workflow should continue as previously
No behavior changes should be observed.
Works as expected.
Signed-off-by: Marc Veron <veron@veron.ch>
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>
To reproduce, edit, index notice with utf-8 char and search for it
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Dobrica Pavlinusic <dpavlin@rot13.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
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>
When placing a new hold, the listed priority for the hold will be
incorrect if there are any holds with items in transit ( i.e. found = T ).
Test Plan:
1) Place 3 holds on a record with at least 2 items
2) Fill one hold so it is marked as waiting
3) Fill on hold so it is marked as in transit
4) Begin placing a new hold
5) Note the expected priority would be 2, but is actually 3
6) Apply this patch
7) Reload the patch, now the expected priority shows correctly
Signed-off-by: Coralie Barsacq <c.barsacq@mairie-laciotat.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
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>
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>
If an item needs to be transferred to fill a hold, the hold will be
listed as 'Waiting to be pulled" while it is in transit.
Test Plan:
1) Place a hold for pickup at another library
2) Check in the item, confirm the hold transfer
3) View the holds for that record ( request.pl )
4) Note the priority is "In transit" and the status is 'Waiting to be
pulled".
5) Apply this patch
6) Reload the holds page
7) Note the status is now "Item being transferred to $branch"
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>
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>
The method of checking the logged in user for superlibrarian privileges
is obtuse ( $userenv && $userenv->{flags} % 2 != 1 ) to say the least.
The codebase is littered with these lines, with no explanation given. It
would be much better if we had one subroutine that returned a boolean
value to tell us if the logged in user is a superlibrarian or not.
Test Plan:
1) Apply this patch
2) Verify superlibrarian behavior remains unchanged
Signed-off-by: Joel Sasse <jsasse@plumcreeklibrary.net>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Comments on second patch.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
On intranet, when placing a hold requst:
If borrower has reached the request limit, a warning should appear :
Cannot place hold
* Too Many Holds: TEST has too many holds.
This works when quota defined in circulation rules is reached but not
when limit specified in syspref maxreserves is reached, in case this
limit is lower than the one defined is circulation rules.
This is because template param maxreserves is set twice, this patch
corrects this bug.
Also moves warnings and messages conditional variable from Perl to
template because it cause the same bug as for maxreserves.
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
One just needed parentheses, but the one on line 219 reflects
a slightly deeper problem -- it's running patron checks when
a patron hasn't actually been supplied.
To test:
[1] From the staff interface, bring up a biblio that has no
holds on it, then go to the holds tab.
[2] Verify that the Apache log has no new warnings containing:
request.pl: Use of uninitialized value in string eq at /home/gmc/koha/reserve/request.pl line 219
or
request.pl: Use of uninitialized value in string eq at /home/gmc/koha/reserve/request.pl line 488
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
