I suppose this is similar to circular dependency on other patch
HoldsQueue uses Circulation uses BatchUpdateBiblioHoldsQueueuse HoldsQueue
Without this the background job builds the queue, but reports failure:
Holds queue for biblio The Jacobite clans of the Great Glen, 1650-1784 /. An error occurred (Undefined subroutine &C4::HoldsQueue::GetTransfers called at /kohadevbox/koha/C4/HoldsQueue.pm line 351. )
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
The CreateQueue() method deletes the holds queue data, fetches some
configuration (branches to use, transport cost matrix) and then loops
through a list of biblionumbers, generating the tmp_holdsqueue and
hold_fill_targets rows for the specified biblio.
This patch simply moves that last bit that is run inside the biblios
loop into a separate sub.
The update_queue_for_biblio sub is designed so it does the exact same
thing it did inside the loop, but also gets added the capability of
querying those parameters if not passed, and it also gets a 'delete'
parameter so it deletes the biblio-specific holds queue rows before
starting to work.
This way, it can be reused to write a background job for real-time holds
queue update :-D
To test:
1. Run:
$ kshell
k$ prove t/db_dependent/HoldsQueue.t
=> SUCCESS: Tests pass!
2. Apply this patch
3. Repeat 1
=> SUCCESS: Tests still pass! Behavior is kept!
4. Sign off :-D
Sponsored-by: Montgomery County Public Libraries
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
and some more...
There are lot of inconsistencies in our ->search calls. We could
simplify some of them, but not in this patch. Here we want to prevent
regressions as much as possible and so don't add unecessary changes.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch makes the code for itemtypeslimit work, and adds options for shelving location and collection code
This also remove the 'post' method from the form to allow easy bookmarking
To test:
1 - Add holds to your system
2 - Run the holds queue builder
3 - Browse to Circulation->Holds queue
4 - Note the library dropdown
5 - Apply patch
6 - Reload and note new options
7 - Test that both limits and 'All' options work as expected
8 - Note that description at top includes options when selected
"### items found for All libraries and item type:(Books)"
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 reverts commit d284735d05.
The following test was failing randomly:
# Failed test 'take from lowest cost branch (don't use cost matrix) holding branch'
# at t/db_dependent/HoldsQueue.t line 1494.
# got: 'LHKtxLk'
# expected: 'JL9C_OR'
# Wrong pick-up/hold for first target (pick_branch, hold_branch, reserves, hold_fill_targets, tmp_holdsqueue)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It makes sense to use items by branch to get the list of branches, as it
already tells use which branches have available items. We could use
branches to pull from instead, but all we would accomplish is added
extra ununsed loop iterations. We already know that any additional
branches in the branches to pull loop have no items to fill holds.
If they did, they would be in the items_by_branch hash.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We no longer need to act as if closed branches were marked as
disable_transfer. This allows us to clean up a nice bit of code.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 28510: Remove unused variable
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Right now we skip closed branch's items as we iterate over all items looking for ones to fill a hold. If HoldsQueueSkipClosed is enabled, no items held be a closed library can be targeted, so it would be more efficient if we never selected the items from those branches to begin with. This is how the holds queue works if we are not using the transport cost matrix, so we should make it work the same way if we *are* using the matrix.
Test Plan:
1) Apply this patch
2) prove prove t/db_dependent/HoldsQueue.t
3) All tests should continue to pass
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
On bug 17591 we discovered that there was something weird going on with
the way we export and use subroutines/modules.
This patch tries to standardize our EXPORT to use EXPORT_OK only.
That way we will need to explicitely define the subroutine we want to
use from a module.
This patch is a squashed version of:
Bug 17600: After export.pl
Bug 17600: After perlimport
Bug 17600: Manual changes
Bug 17600: Other manual changes after second perlimports run
Bug 17600: Fix tests
And a lot of other manual changes.
export.pl is a dirty script that can be found on bug 17600.
"perlimport" is:
git clone https://github.com/oalders/App-perlimports.git
cd App-perlimports/
cpanm --installdeps .
export PERL5LIB="$PERL5LIB:/kohadevbox/koha/App-perlimports/lib"
find . \( -name "*.pl" -o -name "*.pm" \) -exec perl App-perlimports/script/perlimports --inplace-edit --no-preserve-unused --filename {} \;
The ideas of this patch are to:
* use EXPORT_OK instead of EXPORT
* perltidy the EXPORT_OK list
* remove '&' before the subroutine names
* remove some uneeded use statements
* explicitely import the subroutines we need within the controllers or
modules
Note that the private subroutines (starting with _) should not be
exported (and not used from outside of the module except from tests).
EXPORT vs EXPORT_OK (from
https://www.thegeekstuff.com/2010/06/perl-exporter-examples/)
"""
Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access it’s members.
@EXPORT and @EXPORT_OK are the two main variables used during export operation.
@EXPORT contains list of symbols (subroutines and variables) of the module to be exported into the caller namespace.
@EXPORT_OK does export of symbols on demand basis.
"""
If this patch caused a conflict with a patch you wrote prior to its
push:
* Make sure you are not reintroducing a "use" statement that has been
removed
* "$subroutine" is not exported by the C4::$MODULE module
means that you need to add the subroutine to the @EXPORT_OK list
* Bareword "$subroutine" not allowed while "strict subs"
means that you didn't imported the subroutine from the module:
- use $MODULE qw( $subroutine list );
You can also use the fully qualified namespace: C4::$MODULE::$subroutine
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - set AllowHoldItemTypeSelection to 'Allow'
2 - Find a patron from Library A
3 - Find a record with an item from Library A
4 - Place a title level hold with itemtype specified for a delivery at Library A for patron and record above
5 - perl misc/cronjobs/holds/build_holds_queue.pl
6 - There are warns:
Use of uninitialized value in hash element at /kohadevbox/koha/C4/HoldsQueue.pm line 523.
Use of uninitialized value in string eq at /kohadevbox/koha/C4/HoldsQueue.pm line 523
7 - Apply this patch
8 - perl misc/cronjobs/holds/build_holds_queue.pl
9 - No more warns!
10 - prove -v t/db_dependent/HoldsQueue.t
11 - All tests pass!
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If HoldsQueueSkipClosed is enabled, and a library happens to be closed
on the day you edit the transport cost matrix, all the values for that
library will not show. Instead they will appear disabled, and if you
were to edit the cell and save a new value in it, it will also
'disappear' when the page is reloaded.
Test Plan:
1) Set today as a holiday for a library
2) Set HoldsQueueSkipClosed to 'open'
3) Go to the transport cost matrix editor
4) Edit a cell where the 'from' is for the closed library
5) Note the value doesn't 'save', it is still in the database though
6) Apply this patch
7) Restart all the things!
8) Reload the transport cost matrix editor
9) The value now appears correctly!
Signed-off-by: Lisette Scheer <lisetteslatah@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
MapItemsToHoldRequests has three sections: Local holds, item level holds, bib level holds
Only one of them was setting the reserve_id. This patch makes al three set it and adds tests
To test:
1 - Repeat test plan on bug
2 - sudo koha-mysql kohadev
SELECT * FROM hold_fill_targets
3 - Ensure reserve_id is set at appropriate times
4 - prove -v t/db_dependent/HoldsQueue.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Bug 18958: (QA follow-up) Fix number of tests
In HoldsQueue.t
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: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
After looking at Marcel's comments, the problem is in our matching
to hold_fill_targets - rather than adjusting to find filled/waiting holds we
could ensure that hold_fill_targets only refers to the specific hold it
is intended to
This patch is clearer, if slightly less performant than last (we now return all
the reserves and have to find the 'highest')
Test Plan:
1 - Create and use a patron that can place multiple record level holds per record
2 - Create a record with X items, each at a different library
3 - Place X 'Next available' holds on the record for the patron using the 'Holds to place' box
4 - perl misc/cronjobs/holds/build_holdsqueue.pl
5 - Check in LibraryA's copy as LibraryA and confirm the hold
6 - Revisit request.pl for the record, notice the next hold in line is now item-specific
7 - Checkout the item to the patron, notice the remaining hold is marked waiting
8 - Attempt to place another hold for your patron, notice that it requires an item-specific hold
8 - Apply this patch
9 - Repeat steps 1-5
10 - Revisit request.pl for the record, notice the next hold in line has *not* become item-specific
11 - Checkout the item to the patron, ensure the first hold is filled and the second remains record level
12 - Repeat whole test plan without building holds queue to confirm holds are still treated correctly
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.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: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
.pm must not have -x
.t must have -x
.pl must have -x
Test plan:
Apply only the first patch, run the tests and confirm that the failures
make sense
Apply this patch and confirm that the test now returns green
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: Nick Clemens <nick@bywatersolutions.com>
JD amended patch: remove unecessary indentation changes
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds the ability to exclude patrons (by category) from local
holds, and items, by editing the item itself or by batch item
modification tool.
To test:
1. apply patches
2. updatedatabase
3. Enable LocalHoldsPriority preference, and leave
LocalHoldsPriorityPatronControl in pickup library, and
LocalHoldsPriorityItemControl in holding library.
4. Search for a biblio with one item.
5. Place a hold with a patron (patron1) and set pickup location to a different
library of the item's home library
6. Place another hold with another patron (patron2) and set pickup location to be
the same as the item's home library
7. ./misc/cronjobs/holds/build_holds_queue.pl
8. Go to circulation -> holds queue
9. Search by the item's home library
CHECK => only the hold for patron2 (with the pickup location the same as the
item's home library) appears in the table
10. Go back to the biblio details page and click on "Items" tab
CHECK => There is a new section in the item's details between "Statuses"
and "History" called "Priority"
11. Set exclude to "Yes" and update
12. repeat steps 7 to 9
SUCCESS => only the hold for patron1 now appears, even the other hold had local
hold priority
13. Repeat step 10 and 11 but this time set exclude to "No"
14. repeat steps 7 to 9
CHECK => the hold for patron2 is back
15. Edit patron2's category and set exclude from local holds priority to
"Yes"
16. Repeat steps 7 to 9
SUCCESS => the hold for patron1 is back
17. Go to tools -> Batch item modification and in barcode list place
several (existing) barcodes and press continue
CHECK => There is a new section in the bottom called "Priority"
18. Set exclude to "Yes" and save
SUCCESS => all items in the list now have exclude setted to "Yes"
19. Try to checkout the first item to a patron3
SUCCESS => Alert message appears saying that patron1 has a hold on that
item
20. Click on Yes and then checkin that item
SUCCESS => There is a modal window saying that a hold was found for
patron1
21. prove t/db_dependent/HoldsQueue.t t/db_dependent/Holds/LocalHoldsPriority.t
22. Sign off
Sponsored-by: Cooperative Information Network (CIN)
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Added a feature that displays edition information of the book
together with title in "Holds queue" report.
Edition information is fetched from "biblioitem" table
as "editionstatement" and transferred to template.
1. Place a hold on a book with edition information.
2. Run build_holds_queue.pl cron job.
3. Go to /cgi-bin/koha/circ/view_holdsqueue.pl and check the "title"
table of that book that you placed hold on.
4. Observe that there's no information about edition of that book.
5. Apply patch.
6. Repeat step 3.
7. Observe that cinformation about edition of that book appeared
in the title table after book's title and author.
Mentored-by: Andrew Nugged <nugged@gmail.com>
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>
Bug 23934 removed the limitation that prevented item level holds from
getting local holds priority. The problem is the code has never checked
if the item level hold matches the given item! This means the wrong item
may be requested to fill an item level hold.
Test Plan:
1) Create 3 items on a record
2) Place a hold for the 2nd item you created
4) Ensure that hold would be picked up by local holds priority
5) Build the holds queue
6) Note the holds queue is asking for the wrong item!
7) Apply this patch
8) Rebuild the holds queue
9) Holds queue should now be asking for the correct item!
Signed-off-by: Kim Peine <kim@williston.lib.vt.us>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The holds queue builder does not honor
the new item_level_hold flag. Instead, it only item_level_request if
in the loop dealing with item level holds. This is incorrect. Item level
holds may be trapped in the local holds priority loop as well. It's
trivial to just pass though the correct item/biblio level hold flag.
I do not know how to write a reproducable test plan for these issues.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kim Peine <kim@williston.lib.vt.us>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
- Set LocalHoldsPriority to "Give priority for filling holds to patrons
whose pickup library matches the item's holding library"
- set yourself at Library A
- find at item at Library A
- place an item-level hold (Hold 1) for item for pickup at Library B
- set an item-level hold (Hold 2) for item for pickup at Library A
- Confirm Hold 1 shows priority=1
- Check in item
- confirm item would be captured for Hold 2, ignore hold
- run holds queue
- check item in
- confirm item is captured for Hold 2
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Looks like we introduced an error during a rebase somewhere on bug
11529. This patch siply replaces a missng comma in the SQL query for
C4::HoldsQueue::GetHoldsQueueItems.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
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>
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>
Change parameters to a hashref.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Looks good to me.
Two calls in migration_tools/22_to_30 still in old style.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Replaces TRUNCATE by DELETE, since truncate implicitly commits. We don't
need to do that here. (Would complicate testing it too.)
Fixes typo disablig.
Add a simple test to HoldsQueue.t.
Test plan:
Run t/db_dependent/HoldsQueue.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.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>
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>
If LocalHoldsPriority is enabled, and a record level request has more
than one item that could fill that hold, there is a possibility that a
holds queue row will be generated for the request for each of the
available items!
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Joel Sasse <jsasse@plumcreeklibrary.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
It appears that the LocalHoldsPriority feature and the Holds Queue are
fundamentally at odds with each other.
The problem appears to be that both are attempting to choose the best
way to fill holds. When you are using the holds queue and you check in
an item that has been selected by the holds queue builder, that part of
Koha where the LocalHoldsPriority feature lives doesn't get to see all
the holds in order to pick the best one. Instead only the hold selected
by the holds queue builder is returned so to the LocalHoldsPriority
feature, that is only one hold to pick from!
Test Plan:
1) Apply this patch
2) prove t/db_dependent/HoldsQueue.t
3) All tests should pass
Signed-off-by: Barton Chittenden barton@bywatersolutions.com
Signed-off-by: Dani Elder <dani@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Brendan Gallagher <brendan@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>
Some libraries would like to be able to limit hold filling to items that
match the pickup library for a hold based on the item's home or holding
library. The patron's home library should not affect whether a patron
can place the hold, instead the hold will only be fillable when an item
matching the pickup location becomes available.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Note the new "Hold pickup library match" rules for "checkout, hold,
and return policy" and for "holds policy by item type"
4) Set the policy to "item's holding library"
5) Place a hold where the item's holding branch does not match
the pickup branch
6) Check in the item
7) Note it is not trapped for the hold
8) Update the item's holding branch to match the pickup branch
8) Check in the item
9) Note the item is trapped for the hold
10) Repeat steps 4-9 but for home branch instead
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as described
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Mainly a
perl -p -i -e 's/^.*3.07.00.049.*\n//' **/*.pm
Then some adjustements
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
perl -p -i -e 's/^(use vars .*)\$VERSION\s?(.*)/$1$2/' **/*.pm
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Bug 12803 [QA Followup] - Remove use of C4::Dates
C4::Dates was being included, but not used in the code!
Bug 12803 [QA Followup] - Fix koha-qa.pl errors
Bug 12803 [QA Followup] - Update unit tests due to changes in master
Bug 12803 [QA Followup] - Fix to stop failing unit tests
Bug 12803 [QA Followup] - Remove duplicate 'use' lines
Bug 12803 [QA Followup] - Remove NO_CACHE
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
The holds queue is typically generated many times a day in order to
select items to fill holds. Often these items are to be sent to a
different library. However, if the library whose item is picked to fill
a hold is closed, that hold will remain unfilled even if there are other
open libraries who own that item. It would be helpful if we could skip
closed libraries for the purpose of selecting items to fill holds.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Create a record with two items on it, one at Branch A, and one at
Branch B
4) Place a hold for pickup at Branch C
5) Generate the holds queue
6) Note which branch's item is selected for the hold
7) Enable the new system preference HoldsQueueSkipClosed
8) Add today as a holiday for that branch noted in step 6
9) Regenerate the holds queue
10) View the holds queue, notice the item selected is not from
the closed branch!
11) prove t/db_dependent/HoldsQueue.t
Signed-off by: Jason Robb <jrobb@sekls.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
If the transfer of an item from Library A to Library B is disabled in
the Transport Cost Matrix, but the only item on a record is from Library
A, the holds queue will request a transfer of that item from Library A
to Library B even though the rules state such a transfer is not allowed!
Test Plan:
1) Enable the transport cost matrix
2) For simplicity, leave all cells disabled on it, save this state.
This state means that only items at each location should fill
holds where the pickup library is that same location.
3) Create a record with one item, set its home and holding branch
to Library A
4) Create a hold for pickup at Library B
5) Rebuild the holds queue
6) Note the transfer request for the item to Library B
7) Apply this patch
8) Rebuild the holds queue
9) Note the transfer request is gone
Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If a record has a hold on it where the pickup and home branch do not
match, the holds queue builder will only look at items from the least
cost branch ( as defined by the transport cost matrix or the sys pref
StaticHoldsQueueWeight.
Test Plan:
1) Create a record with two items, one for library A and one for library B
2) Set your circulation rules such that the book from library A is
holdable by all and the book from library B is holdable only by library
B patrons
3) Create a hold for a Library C patron for pickup at library C
4) Set the syspref StaticHoldsQueueWeight to by Library B, Library A,
Library C in that order
5) Rebuild the holds queue
6) Note the hold wasn't picked up even though the item from library A
could have filled the hold
7) Apply this patch
8) Rebuild the holds queue
9) View the holds queue again
10) Note the hold now displays
Signed-off-by: Nora Blake <nblake@masslibsystem.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
