Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 007d66e314)
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
This patch adds a catch during circulatoin actions and passes a message back to the caller
For checkouts and renewals we don't have a method for passing messages so we simply catch the exception
and warn - this seems reasonable, as we have now added a warning on the patron display that they are missing
a guarantor
To test:
1 - Create a Child type patron with no guarantor
2 - Create a patron in a non-child category that can_be_guarantee with no guarantor
3 - Check out an item to each patron above
4 - Enable system preference 'ChildNeedsGuarantor' and TrackLastPatronActivityTriggers - select all
5 - In mysql
UPDATE borrowers SET datelastseen = '2025-01-01';
6 - Restart all to clear cache (so update last seen will update)
7 - Attempt to checkout a book to either patron - 500 error
8 - Attempt to returnt he books the patrons have checked out - 500 error
9 - Attempt to renew their items - 500 error
10 - Apply patches, restart all
11 - Repeat checkout, renewal, checkin
12 - On checkout and renewal there should be a warning on the patron page, but actions succeed with no additional problems
13 - On return you get a warning letting you know the action succeeded but there is still a problem to resolve
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit bd32425271)
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch ignores limits when updating a wrong transfer to ensure we can return a book
home when checked in at the wrong branch
To test:
1 - Enable UseBranchTransferLimits based on 'Collection code'
2 - Disable transfers for FIC from:
CPL -> FFL
CPL -> IPT
FFL -> CPL
FFL -> IPT
IPT -> CPL
IPT -> FFL
3 - Set library to IPT
4 - Checkin an FFL item
5 - It generates a transfer home
6 - Set library to CPL
7 - Check the item in
8 - 500 error, and in logs:
==> /var/log/koha/kohadev/plack-error.log <==
Exception 'Koha::Exceptions::Item::Transfer::Limit' thrown 'Transfer not allowed'
9 - Apply patch, restart all
10 - Check item in again
11 - Success! Transfer updated
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Checkins can disappear from the checkin list if transfer modal is
triggered.
There is a flaw in the logic of the checkin code: we keep 20 (default
value for numReturnedItemsToShow) checkins in the table, but there can
be shift in the "counter" logic when the transfer modal is triggered.
This patch is removing the different hashes and use a single @checkins
array to pass to the template.
When a item is checked in, it is inserted at the beginning of the list
(unshift). Koha::Objects are passed for patron, item and biblio to
improve the readability (and maintenance cost) of the code.
Test plan:
Generate several checkouts (see below)
Some should generate the transfer modal
Check them in
=> Without this patch notice that at some point there will be a problem
in the list, some checkins will be missing.
=> With this patch applied the checkin list always contain the last 20
checkins (or whatever is the value of numReturnedItemsToShow, or "8"
if pref is empty, don't ask why 8!)
Code to generate 50 checkouts (all overdue):
```
use C4::Circulation qw( AddIssue );
use Koha::Items;
use Koha::Patrons;
use t::lib::Mocks;
use Koha::DateUtils qw(dt_from_string);
my $patron = Koha::Patrons->find(51);
t::lib::Mocks::mock_userenv({patron => $patron});
my $items = Koha::Items->search;
my $patron_unblessed = $patron->unblessed;
my $i;
while ( my $item = $items->next ) {
my $due = dt_from_string->subtract(days => 45 + rand(45))->set_hour(23)->set_minute(59)->set_second(00);
AddIssue($patron, $item->barcode, $due);
last if ++$i >= 50;
}
```
Then retrieve the barcodes:
> SELECT items.barcode FROM issues LEFT JOIN items ON items.itemnumber=issues.itemnumber;
QA:
1. Do not be afraid by the length of this patch, most of the changes are
variable renames.
2. return_overdue is now only calculated once per checkin (per page
load, could be improved)
3. date formatting is done template-side
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The FIXME correctly stated that the CheckReserves call and follow-up
only should be executed within the cancel hold scope.
NOTE: Actually, I do not see how to trigger it in current code. Since
checking in a waiting hold triggers the NotIssued error. And the
cancel hold button is not available for holds in queue.
Test plan:
Place a hold on an item.
Checkin at pickup location. Confirm. Hold waiting now?
Try again but checkin at another branch. Transfer triggered?
The hard part (see my note). Try to get at the form where you can
cancel the hold (waiting or first in queue).
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan:
Enable future holds. Put a positive value in ConfirmFutureHolds.
Add a hold for tomorrow and pickup at B. Check item in at A.
Confirm hold.
Without this patch you should see a warn on L186:
[WARN] Use of uninitialized value in string ne at /usr/share/koha/circ/returns.pl line 186.
With this patch, you should not see it anymore.
NOTE: Before bug 34972 no transfer was created for future holds.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This commit is generated using:
% perl misc/devel/tidy.pl
*within* ktd, to get the same version of perltidy than what will be used
by our CI (currently v20230309).
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The call expects a library object, not a branchcode, likely rebasing issue
To test:
1 - Place a hold for an item at a different library than current library
2 - Check item in and confirm transfer
3 - Check item in again
4 - Kaboom!
5 - Apply patch/restart_all
6 - Check item in again
7 - Ok!
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
[WARN] Use of uninitialized value $op in string eq at /usr/share/koha/intranet/cgi-bin/circ/circulation.pl line 144.
[WARN] Use of uninitialized value $op in string eq at /usr/share/koha/intranet/cgi-bin/circ/returns.pl line 253.
These happen in cases when $op is undef and circulation.pl or returns.pl tries to directly compare it to a string.
To reproduce:
1. Go to "Check Out" and "Check In" circulation pages, or refresh already opened one.
2. Check your logs for "Use of uninitialized value $op" warning.
3. Apply patch.
4. Repeat step 1 and check that no new "Use of uninitialized value $op" error were logged.
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch removes the last remaining use of updateWrongTransfer and the
method itself.
We replace it with a call to request_transfer that passes the 'replace'
reason of 'WrongTransfer' through to Koha::Item::Transfer->cancel.
Test plan
1/ git grep updateWrongTransfer to confirm there are no more uses of the
method.
2/ Confirm an incorrect transfer still behaves as expected at
circulation returns.
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch replaces the call to ModItemTransfer in circ/returns.pl with
a call to Koha::Item->request_transfer and
Koha::Item::Transfer->transit.
Test plan
1) Set 'AutomaticItemReturn' to "Don't"
2) Check an item in at a location other than it's 'home' or 'holding'
branch
3) Note you should be asked a about returning the item to another branch
4) Opting to not proceed should NOT result in a row in the
branchtransfers table
5) Option to proceed (either with a print slip or just 'OK') should
result in a branchtransfer from the current checkin branch to the
home or holding branch depending on the circulation rules.
5a) The item should be marked as immediately in transit in, i.e. the
'datesent' set to today.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Andrew Fuerste Henry <andrewfh@dubcolib.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
1) Don't automagically always set a transfer to in transit on checkin..
wait for the user to actually confirm that's the case
2) New transfers triggered by a hold should take precidence, so hide
transfers for any other reason from display
3) Update get_transfer and get_transfers to ensure ordering isn't lost
when prefetch is used and add tests for this
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
In returns.pl we find a patron, then use it in an if statement.
Test Plan:
Cancel a hold with other holds remaining on the record.
No change should be noted.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Upadates for CSRF are inadvertently stopping AddReturn from being trigger
when a hold is canceled. This is necessary to generate the transfer
back to the originating library.
Test Plan:
1) Find item with a waiting hold, and check it in
2) In the popup notifying me of the waiting hold, select 'Cancel hold'
3) Note no second popup appears notifying you of the need to transfer the item to its home library
4) Apply this patch
5) Restart all the things!
6) Repeat steps 1-2
7) Second popup appears!
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The bug report addresses an issue where the message "Item was not checked in" erroneously appears during the second POST after a manual or modal check-in process.
1. In circ/returns.pl:
- Introduced a new hash `%rinot_returned` to track items not returned across pages.
- Updated the logic to capture the "not returned" status from the query parameters.
- Adjusted the input processing loop to include `not_returned` status.
- Modified the section handling barcode check-ins to appropriately initialize and update the `not_returned` status.
2. returns.tt:
- Added hidden input fields in the template to include `not_returned` status in the form submissions.
The changes ensure that the "not_returned" status is correctly tracked and displayed, preventing the erroneous message from appearing on subsequent POST requests.
1. Perform a manual check-in of an item, but make some warning modal appear: for ex., transfer: check-in the item in not home library.
2. Press OK on the modal. There will be a POST transition again to redraw the checked-in items list.
3. Verify that the "Item was not checked in" message appears erroneously near the item's row.
4. Apply the patch.
5. Repeat steps 1-3 and check that there will be no erroneous "Item was not checked in" message.
Signed-off-by: Tadeusz „tadzik” Sośnierz <tadeusz@sosnierz.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
GetOtherReserves attempts to set the waiting/transit status for the next
hold on the list when applicable, but in practice it either leaves the
hold state unchanged, or sets the itemnumber without setting the found
status (erroneously converting bib-level holds to item-level holds).
The latter situation only occurs when the user has been prompted to
confirm, cancel, or revert the hold, and is able to ignore the prompt.
In those situations, the hold's state should not change.
GetOtherReserves does not need to change the hold state, and it does not
do so correctly. Besides that, it does not do much other than call
CheckReserves, and is only used in 3 places.
This patch removes GetOtherReserves, and refactors returns.pl and
C4::Reserves::ModReserveCancelAll to call CheckReserves directly instead.
To test:
1. Place 2 bib-level holds for 2 different patrons (Patron A and Patron
B) on the same record, both for pickup at the logged-in library
2. Check in an item from that record to fill Patron A's hold
3. Set the hold's expiration date to yesterday by accessing the database
in the command line:
- In a ktd shell prompt, open the db client with koha-mysql kohadev
- UPDATE reserves
SET expirationdate = DATE_SUB(CURDATE(), INTERVAL 1 DAY)
WHERE borrowernumber = <Patron A's borrowernumber>
4. Go to Circulation > Holds Awaiting Pickup, and find the hold in the
"holds waiting past their expiration date" tab
5. Click the "Cancel hold" button in the Actions column next to the hold
(do not check in the book)
6. Return to the bib record and look at Patron B's hold
--> Note that Patron B's hold is now an item-level hold and does not
have a waiting status
7. Cancel Patron B's hold
8. Place 2 new holds on the record: one for Patron A at the logged-in
library, and one for Patron B at a different library
9. Check in an item to fill Patron A's hold
10. Repeat steps 3-5 to expire and cancel Patron A's hold
11. Return to the Holds tab of the bib record and look at Patron B's hold
--> Note that Patron B's hold is now an item-level hold, and there is no
"Revert transit status" button
12. Place 2 bib-level holds for 2 different patrons (Patron A and Patron
B) on the same record, both for pickup at the logged-in library
13. Check in an item from that record to fill Patron A's hold
14. Check in the same item again. A modal will pop up, saying that the
hold is already waiting
15. In the modal, choose a cancellation reason and click "Cancel hold"
--> A new modal will pop up to fill Patron B's hold
16. Click "Ignore" on the modal for Patron B's hold
17. Return to the bib record and look at Patron B's hold
--> Note that Patron B's hold is now an item-level hold and does not
have a waiting status
18. Apply patch
19. Repeat steps 1-6
--> Note that Patron B's hold is still a bib-level/"next available" hold
20. Repeat steps 7-11
--> Note that Patron B's hold is still a bib-level/"next available" hold
21. Repeat steps 12-17
--> Note that Patron B's hold is still a bib-level/"next available" hold
Make sure correct behavior is unchanged:
22. Cancel Patron B's hold
23. Place 2 new holds on the record: one for Patron A at the logged-in
library, and one for Patron B at a different library
24. Check in an item from that record to fill Patron A's hold
25. Check in the same item again. A modal will pop up, saying that the
hold is already waiting
26. In the modal, choose a cancellation reason and click "Cancel hold"
--> A new modal will pop up to fill Patron B's hold
27. Click "Print slip, transfer, and confirm" on the modal for Patron B's hold
--> Confirm that the information on the slip is correct
--> Confirm that the hold is correctly put in transit
22. Set HoldsAutoFill and HoldsAutoFillPrintSlip to "Do"
23. Place a bib-level hold for the logged-in library
24. Check in an item from that bib
--> Confirm the information on the slip is correct
--> Confirm the hold is correctly assigned and set to waiting
25. Place a bib-level hold for a different library
26. Check in an item from that bib
--> Confirm the information on the slip is correct
--> Confirm the hold is correctly put in transit
27. Change the logged-in branch to match the hold pickup location
28. Check the item in
--> Confirm the information on the slip is correct
--> Confirm the hold is correctly assigned and set to waiting
29. Repeat steps 22-26
--> Confirm a correct hold slip pops up for Patron B's hold
--> Confirm that Patron B's hold is correctly put in transit
30. Cancel Patron B's hold
31. Place 2 bib-level holds for 2 different patrons (Patron A and Patron
B) on the same record, both for pickup at the logged-in library
33. Repeat steps 24-26
--> Confirm a correct hold slip pops up for Patron B's hold
--> Confirm Patron B's hold is correctly set to Waiting
34. Prove t/db_dependent/Circulation.t
35. Prove t/db_dependent/Koha/Holds.t
--> Tests pass
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Configure Claims returned
1. Go to Administration > Authorized Values > LOST
2. Add a new authorized value with value:6 and description:Claims returned
3. Go to Administration > System Preferences
4. Set ClaimReturnedLostValue to 6 and save
2. Check out an item to a patron.
1. Mark the item as claim returned
2. Check the item in.
3. A message stating that the item has been claimed as returned pops up with
an option to resolve.
4. Resolve the claim.
3. Check out the item to the patron again.
1. Mark the item as claim returned.
2. Check out the item to a new patron. Select “Yes, check out”
3. Go back to the previous patron. Notice that their claim was not resolved.
4. Apply the patch.
1. Updatedatabase
2. restart_all
3. Go to the system preferences and set the system preference
‘AutoClaimReturnStatusOnCheckin’ to ‘Returned by patron’
4. Set ‘AutoClaimReturnStatusOnCheckout’ to ‘Found in library’
5. Redo step 2
1. When checking the claim returned item in you will now see a message that
says “The previously claimed returned item has been found, automatically
resolving the associated claim.”
2. View the previous patron. Their claim has automatically been resolved
with a status of ‘Returned by patron’
6. Redo step 3
1. Upon checking the item out to another patron you will see a message that
says “The previously claimed returned item has been found, automatically
resolving the associated claim.”
2. View the previous patron. Their claim has automatically been resolved
with a status of ‘Found in library’.
7. Sign off and have a wonderful day!
Sponsored-by: Altadena Library District
Signed-off-by: Andrew Fuerste Henry <andrewfh@dubcolib.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch displays the due date and withdrawn information in the Checked-in items table when 'ShowAllCheckins' is enabled. While the top message is clear, if a staff member checks in two items, then refers to the table they would not have all the information.
To test:
1 - Enable system preference 'ShowAllCheckins'
2 - Set system preference 'BlockReturnOfWithdrawnItems' to 'Block'
3 - Check out an item to a patron
4 - Mark the item as withdrawn
5 - Check the item in
6 - Note message at top says things like 'Cannot check in' 'Item has been withdrawn'
7 - Note the Checked-in items table says 'Not checked out'
8 - Apply patch, restart all
9 - Check the item in again
10 - Note top message has not changed
11 - Note the table now say 'Item was not checked in' and displays the due date and patron info
12 - Note the table also includes the withdrawn value for the item
Signed-off-by: Andrew Fuerste Henry <andrewfh@dubcolib.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan:
1) Check an item in with already a confirmed hold
2) Cancel the hold, it was cancelled without possibility to choosing a
reason
3) Apply this patch and do it again, you must see an input to choose
your cancellation reason (list from VA)
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This follow-up patch removes the use of $exit_required_p completely. The sysprefs BlockReturnOfLostItems and BlockReturnOfWithdrawnItems are handled in other scripts, and should not prevent the processing of all returns error messages when enabled.
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This fix ensures that a return claim confirmation always shows, even if
the return of lost items has been blocked by BlockReturnOfLostItems
being enabled.
To test:
1. Set BlockReturnOfLostItems system preference to Block
2. Check out an item to a patron
3. Go to the patrons page and claim a return on the item
4. Check in the item and keep checking in the item. Notice the message
"Item is lost, cannot be checked in." shows every time, but the return
claim message only shows sometimes.
5. Apply the patch and restart services
6. Check in the item and keep checking in the item. Confirm both the
lost message shows and the return claim message shows every time.
7. Confirm the return of the item is still blocked.
Sponsored-by: Pymble Ladies' College
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1. Apply patch, restart_all
2. Check some items out and prepare some reasons that would initiate a branchtransfer. According the schema it can be any of the following: 'Manual', 'StockrotationAdvance', 'StockrotationRepatriation', 'ReturnToHome', 'ReturnToHolding', 'RotatingCollection', 'Reserve', 'LostReserve', 'CancelReserve', 'TransferCancellation', 'Recall', 'RecallCancellation.
3. CHeck in some the items and notice the 'Transfer reason' column in the table. Make sure the reasons are acurate and make sense.
4. To go Table settings and find the 'checkedintable'. Make sure you can properly hide the column from the display.
Signed-off-by: AndrewA <andrew.auld@ptfs-europe.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Bug 22284 introduced ability to create hold groups.
We should have ability to create float groups in
same manner. This patch adds checkbox "Is local
float group" to group creation feature and new return
policy "Item floats by librarygroup".
To test:
1. Add new float group and some libraries to it.
2. From circulation and fine rules, set default
return policy as "Item floats by library group".
3. Check out an item for a patron.
4. Set library as one that belongs in the same
float group.
5. Check in the item.
=> Observe that notice for transfer doesn't pop up.
6. Check out again.
7. This time set library as one that doen's
belong in the same float group.
8. Check in.
=> Observe that notice for transfer pops up.
Experiment this feature by changing return policy
per library, item type etc.
Also prove t/db_dependent/Koha/Libraries.t
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Lisette Scheer <lisettePalouse+Koha@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds a button in the "bundle verification" modal to skip
this step and do the checkin anyway.
Test plan:
1. Create an items bundle (see bug 28854 comment 458)
2. Check out this bundle, then return it. The "bundle verification"
modal should appear
3. Leave the textarea empty and click on "Confirm checkin without
verifying bundle contents"
4. Confirm that the bundle was correctly returned, and no items were
marked as lost
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This enhancement gives the ability to set a policy for the lost item
processing fee that may get charged additional to the lost item
replacement cost. The processing fee can be:
- refunded
- refunded if unpaid
- kept
To test:
Set-up
1. Find an item, Item A. Go to Administration -> Item types and edit the
item type for Item A. Add a default replacement cost and a processing
fee and Save.
2. Go to Administration -> system preferences and set the following:
- WhenLostChargeReplacementFee: Charge
- BlockReturnOfLostItems: Don't block
3. Scroll down to the default lost item fee refund on return policy. Set
the refund lost item replacement fee policy to 'refund lost item charge'.
4. Edit Item A and set a replacement cost.
Reproduce
5. Check out Item A to Patron A.
6. Click the barcode to view Item A's information. Edit Item A and set
the Lost status to 'lost'.
7. Go back to Patron A's checkouts. The item should now be checked in
with two new charges applied - a lost item fee (the item's replacement
cost) and a lost item processing fee (set in item types).
8. Check in Item A to mark it as found.
9. Go back to Patron A's account. Notice the lost item fee has been
refunded, but the processing fee remains.
10. Manually pay or write off the processing fee. This enhancement
removes the need for this manual step.
11. Apply the patch and restart services
Test with lost item - refund
12. Go to Administration -> circulation and fines rules. Scroll down to
the default lost item fee refund on return policy. Notice there is now a
refund lost item processing fee policy. Set this to 'refund lost item
processing charge'.
13. Repeat steps 6 to 9.
14. Go back to Patron A's account. Both the lost item fee and processing
fee should have been refunded.
15. Repeat steps 6 to 8 (do not check it yet).
16. Go back to Patron A's account. Pay the processing fee.
17. Repeat step 9.
18. Go back to Patron A's account. Both the lost item fee and processing
fee should have been refunded (you'll now be in a credit because the
paid processing fee was also refunded).
Test with lost item - refund_unpaid
19. Go to Administration -> circulation and fines rules. Scroll down to
the default lost item fee refund on return policy. Notice there is now a
refund lost item processing fee policy. Set this to 'refund lost item
processing charge (only if unpaid)'.
20. Repeat steps 6 to 9.
21. Go back to Patron A's account. Both the lost item fee and processing
fee should have been refunded.
22. Repeat steps 16 to 19.
23. Go back to Patron A's account. The lost item fee should have been
refunded but not the processing fee, as this was already paid.
Test with lost item - leave
24. Go to Administration -> circulation and fines rules. Scroll down to
the default lost item fee refund on return policy. Notice there is now a
refund lost item processing fee policy. Set this to 'leave lost item
processing charge'.
25. Repeat steps 6 to 9.
26. Go back to Patron A's account. The lost item fee and processing fee
should have been refunded but not the processing fee.
Other tests
27. Confirm tests pass
- t/db_dependent/Koha/Item.t
- t/db_dependent/Koha/CirculationRules.t
Sponsored-by: Auckland University of Technology
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
1) Apply this patch
2) Run updatedatabase.pl
3) Verify CircControlReturnsBranch is set to home library by default
4) Set a Return policy for Branch A to "Item returns home" ( homebranch )
5) Set a Return polity for Branch B to "Item returns to issuing library" ( holdingbranch )
6) Set a Return polity for Branch C to "Item floats" ( noreturn )
7) Create an item with homebranch of Branch A, holding branch of branch B
8) Log in as Branch C
9) Set CircControlReturnsBranch to "the library the item is currently held by"
10) Check the item in, note it should be returned to the holding library
11) Set CircControlReturnsBranch to "the library the item is owned by"
12) Check the item in, note it should be returned to the home library
13) Set CircControlReturnsBranch to "the library you are logged in at"
14) Check the item in, note it should float
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Replaced the hardcoded 20 by the value of numReturnedItemsToShow to
display the right number of items in check in.
Test plan:
1- Make lots of checkouts, at least like 40 (I used the batchCheckouts feature)
2- Go to Circulation > Check in
3- Return 21 items
The last 20 items returned will be displayed
4- Change numReturnedItemsToShow to 50
5- Return a couple more items
Only the last 20 returned items are displayed
6- Change numReturnedItemsToShow to 10
7- Return a couple more items
Only the last 10 returned items are displayed
8- Apply the patch
9- Change numReturnedItemsToShow back to 20
10- Do steps 1 to 7 again, but this time step 5 returns the right amount
of items
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch makes the code dealing with waiting holds with cancellation
requests be dependent on the fact an item has been found.
The returns.pl controller is a bit messy as the real return takes place
outside the main `if ($item)` block. This should be refactored and
probably run inside a transaction...
In the meantime this patch will make the job.
To test:
1. Try to return an invalid barcode (e.g. ASDQWE)
=> FAIL: Things explode
2. Apply this patch
3. Repeat 1
=> SUCCESS: Doesn't explode!
4. Verify that returning an item with a waiting hold with cancellation
requests still cancells the hold.
=> SUCCESS: It does!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The idea rely on the KohaDates TT plugin for the date formatting. We
should not have any output_pref calls in pl or pm (there are some
exceptions, for ILSDI for instance).
Also flatpickr will deal with the places where dates are inputed. We
will pass the raw SQL value (what we call 'iso' in Koha::DateUtils), and
the controller will receive the same value, no need to additional
conversion.
Note that DBIC has the capability to auto-deflate DateTime objects,
which makes things way easier. We can either pass the value we receive
from the controller, or pass a DT object to our methods.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch makes checkin process the cancellation requested holds
actually cancel them before moving forward.
To test:
1. Have a waiting hold with a patron generated cancellation request
2. At circulation, check the item in
=> SUCCESS: The workflow follows as if the cancellation requested hold
was already cancelled
=> SUCCESS: The hold is actually cancelled
=> SUCCESS: Not shown in the OPAC anymore
Sponsored-by: Montgomery County Public Libraries
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The code in here is weird.. we really aught to check for the item before
anything else and throw an error to screen if we don't find one... but
my patch takes the simple option, and the one taken elsewhere in the
script.. to just check for item being defined before calling a method
upon it.
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds a further modal to the post checkin alert to allow the
user to print a view and print a list of items that went missing at this
checkin to allow for replacements to be picked.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch records the bundle issue from which an item is marked as lost
so that we may use that to infer who lost the item (for later charges
and display).
Test plan
0) Apply all patches up to this point
1) Checkout a bundle to a user
2) Checkin the bundle and do not scan one of the barcodes at
confirmation
* Note that the item not scanned is marked as lost
3) Navigate to the biblio for the lost item and note that it is marked
as lost.
4) Navigate to the biblio for the collection and expand the collection
item that contains the lost item. Note the item is marked as lost and
checkout details are listed.
5) Checkin the lost item
* The item should be marked as found and the return_claims line should
be marked as resolved.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch updates the circulation system to account for bundle
checkins. We add a content verification step to ensure bundle content is
all present at checkin and we use this comparison to mark missing items
as lost.
Test plan
0) Apply patches up to this point
1) Checkin an item that belongs to a bundle
* An alert should be triggered noting that the item belongs to a
bundle
* The option to remove the item from the bundle should be clear
* Click remove should result in the alert dissapearing and the item
having been removed from the bundle.
2) Checkin an item bundle
* A modal confirmation dialog should appear requesting each item
barcode be scanned
* As items are scanned they should be highlighted in yellow in the
bundle content table
* Upon submission;
* The user will be alerted to any unexpected items that were
scanned and told to put them to one side.
* The user will be alerted that any missing items in the validation
will have been marked as lost.
* The bundle item will be marked as checked in.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Barcode is trimmed of leading/trailing whitespaces in many instances
before the barcodedecode sub was called. This patch instead makes that
barcodedecode sub is going to trim it itself and removes unnecessary,
and repetitive code that was used before barcodedecode was called.
Steps to test:
1. Edit item with any barcode, add a bunch of whitespaces at the start
and at the bottom of it. Save the item. Ensure that this action ruins
the barcode and ensure that the spaces are still there by editing the
same item again.
2. Apply the patch.
3. Edit the same item again in the same fashion. Ensure that now all
whitespaces are getting trimmed and it doesn't affect the barcode in
any negative way.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Baptiste Wojtkowski
Nick Clemens
Jonathan Druart
Marcel de Rooy
Koha Development Team
Andrii Nugged
Martin Renvoize
Kyle M Hall
Matt Blenkinsop
Emily Lamancusa
Laura Escamilla
Thibaud Guillot
Aleisha Amohia
Lucas Gass
Emmi Takkinen
Julian Maurice
Shi Yao Wang
Tomas Cohen Arazi
Petro Vashchuk