This patch prevents deletion of items that have item level holds on
them.
Test plan:
1. Create an item level hold.
2. Delete the item using alternative A or B:
A. Open the biblios Detail-view -> From the toolbar, open
"Edit"-dropdown menu -> Manage items -> Delete the item that has
an item level hold attached to it from "Actions"-dropdown menu
B. Open the biblios Detail-view -> Select the item that has an item
level hold attached to it -> Click "Delete selected items" ->
Confirm deletion
3. Notice that the item is deleted without any warning and the item
level hold has disappeared.
4. Apply this patch.
5. Repeat steps 1-3.
6. Notice that the item cannot be deleted and a warning is shown.
7. prove t/db_dependent/Koha/Item.t
8. Run the REST API tests: prove t/db_dependent/api/v1/items.t
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This commit completely modernizes the hold fee system by migrating from
the deprecated categories.reservefee column to the circulation rules framework
and implementing modern Koha::Objects patterns.
WHAT CHANGED:
1. MIGRATION TO CIRCULATION RULES:
- Moved hold fees from categories.reservefee to circulation_rules table
- Added database migration script with atomic update
- Maintains existing fee amounts during migration
- Provides rule hierarchy: category+itemtype+branch specific rules
2. NEW SYSTEM PREFERENCE: TitleHoldFeeStrategy
- Options: highest, lowest, most_common
- Addresses inconsistent title-level hold fees when items have different fees
- Default: 'highest' (safest approach for library revenue)
3. MODERN Koha::Objects API:
- Koha::Item->holds_fee($patron): Calculate fee for specific item
- Koha::Hold->calculate_hold_fee(): Enhanced item/title-level logic
- Koha::Hold->should_charge($stage): Centralized charging logic
- Koha::Hold->charge_hold_fee(): Modern fee charging with proper accounting
- Removed C4::Reserves::GetReserveFee and ChargeReserveFee
4. ENHANCED FUNCTIONALITY:
- Proper ReservesControlBranch logic (patron home vs item home library)
- Complete HoldFeeMode implementation (placement/collection/not_always)
- Clear OPAC messaging with "You will be charged..." commitment
- Comprehensive test coverage for all fee scenarios
5. TECHNICAL IMPROVEMENTS:
- Object-oriented design following Koha patterns
- Proper error handling and edge case management
- Modern test structure with comprehensive coverage
- Clean separation between fee calculation and charging
TEST PLAN:
A) MIGRATION AND SETUP:
1. Apply all patches and run database update
2. Verify existing hold fees migrated to circulation rules:
- Administration > Circulation and fine rules
- Previous categories.reservefee values now in "Hold fee" column
3. Confirm old categories.reservefee column no longer used
B) BASIC FEE CALCULATION:
1. Set up patron categories with different hold fees in circulation rules
2. Create items with different item types, each with different hold fees
3. Test item-level holds charge correct fees based on specific item
4. Test title-level holds use TitleHoldFeeStrategy preference
C) TITLE-LEVEL HOLD STRATEGIES:
1. Set TitleHoldFeeStrategy to "highest":
- Create title with items having fees $1.00, $2.00, $3.00
- Verify title-level holds charge $3.00
2. Set TitleHoldFeeStrategy to "lowest":
- Verify same title charges $1.00
3. Set TitleHoldFeeStrategy to "most_common":
- Add multiple items with $2.00 fee
- Verify title-level holds charge $2.00 (most common)
D) HOLDFEEMODE PREFERENCES:
1. Set HoldFeeMode to "any_time_is_placed":
- Place holds and verify immediate fee charging
- Check patron account for correct hold fee debits
2. Set HoldFeeMode to "any_time_is_collected":
- Place holds, verify no immediate charges
- Check out items to patron, verify fee charged on collection
3. Set HoldFeeMode to "not_always":
- With available items: verify no fee charged
- With all items checked out but no other holds: verify no fee
- With all items checked out and other holds exist: verify fee charged
E) RULE HIERARCHY TESTING:
1. Set different fees for different category/itemtype/branch combinations
2. Verify most specific rule applies:
- Branch + Category + ItemType (most specific)
- Category + ItemType
- Category only (most general)
3. Test with different patron categories and item types
F) USER INTERFACE TESTING:
1. OPAC interface:
- Verify "You will be charged..." messages display correct amounts
- Test both item-level and title-level hold fee messages
- Confirm fees match actual charges in patron account
2. Staff interface:
- Place holds for patrons and verify fee calculations
- Check Administration > Circulation rules interface works correctly
G) EDGE CASES AND ERROR HANDLING:
1. Test $0.00 fees (no charge scenarios)
2. Test patrons with no applicable fee rules (should default to $0.00)
3. Test items with no holdable copies (should return $0.00)
4. Test invalid/missing itemtypes or categories
5. Test holds on biblios with no items
H) REGRESSION TESTING:
1. Verify existing hold placement workflows unchanged
2. Check patron account charging remains accurate
3. Confirm OPAC and staff interfaces display correctly
4. Test that existing holds continue to work properly
I) UNIT TESTS:
Run the following test suites to verify functionality:
- prove t/db_dependent/Koha/Hold.t
- prove t/db_dependent/Koha/Item.t
- prove t/db_dependent/Reserves.t
- prove t/db_dependent/Circulation.t
BACKWARDS COMPATIBILITY:
- All existing functionality preserved
- Hold fee amounts maintained during migration
- Existing workflows continue unchanged
- Legacy code updated to use new API seamlessly
Sponsored-by: OpenFifth <https://openfifth.co.uk>
Signed-off-by: Jackie Usher <jackie.usher@westsussex.gov.uk>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Generated using
`perl misc/devel/tidy.pl --perl`
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
1. APPLY patch, restart_all, updatedatabase
2. Search for the StoreLastBorrower system preference, it should now allow you to enter a number of borrowers to store
3. Set the pref to 3.
4. Check an item out to any patron. Then immediately check it back in.
5. On catalogue/moredetail.pl?biblionumber=X ( where X is you biblionumber ) you should see a "Last returned by:" entry with the correct cardnumber for the borrower.
7. Confirm this is right in the database with: SELECT * FROM items_last_borrower where itemnumber = X; ( Where X is your itemnumber )
8. Repeat step 4 to a different borrower.
9. Repeat steps 5 and 6. You should see 2 cardnumbers of each of the borrowers on catalogue/moredetail.pl?biblionumber=X
10. Repeat step 4 with another new borrower.
11. Repeat steps 5 and 6. You should see 3 cardnumbers of each of the borrowers on catalogue/moredetail.pl?biblionumber=X
12. Choose a different item and repeat steps 4 - 11 for this item.
13. Now set the StoreLastBorrower preference to 0.
14. Using the original item from step 4, check something out to a patron and immediately check it back in.
15. catalogue/moredetail.pl?biblionumber=X should NOT have an entry for "Last returned by:"
16. Check the database, all entries for the itemnumber from step 14 should be deleted.
Signed-off-by: Trevor Diamond <trevor.diamond@mainlib.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
CanBookBeRenewed will by default pass the skip_future_holds flag
to item->current_holds so that renewals are not blocked by future
holds.
The new pref FutureHoldsBlockRenewals allows you to change that
historical behavior.
Test plan:
[1] Set pref ConfirmFutureHolds=3, FutureHoldsBlockRenewals=Allow,
OPACAllowHoldDateInFuture=Allow
[2] Checkout some item to patron A.
[3] Place hold on same item for patron B, reserve date tomorrow.
[4] Try to renew item with patron A on account page. Should be
marked as Not renewable.
[5] Set pref FutureHoldsBlockRenewals=Dont
[6] Repeat step 4. Renew should be allowed.
[7] prove t/db_dependent/Holds.t t/db_dependent/Reserves.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1. prove t/db_dependent/Koha/Item.t
2. Observe success
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Currently request_transfer checks for the existence of a current transfer on the item, and a new one can either be
enqueued or replace this transfer. This patch adds a check to see if the requested transfer matches an existing transfer
on the item. In the case that it does we simply return that transfer rather than create a new transfer.
This has the effect of eliminating 'WrongTransfer' generation if an item is checked in twice at the same branch, which feels correct.
To test:
1 - place a hold on an item that is currently at branch A, for pickup at branch B
2 - check your item in at Branch A, click to confirm the hold and transfer (print slip if you want to)
3 - sudo koha-mysql kohadev: SELECT * FROM branchtransfers -- See one transfer
4 - check your item in at Branch A again, get a message that the item is supposed to go to Branch B. Don't click on the modal yet
5 - repeat 3 -- See two transfers, one cancelled as WrongTransfer, one pending
6 - Click 'Confirm and transfer' on the modal
7 - repeat 3 -- See three tranfers - the two from before and a new active transfer
8 - DELETE FROM branchtransfers
9 - Apply patch, restart all
10 - repeat 3 - no transfers
11 - Check item in at branch A again and confirm
12 - repeat 3, one transfer
13 - Check item in, don't confirm the modal
14 - repeat 3, one transfer
15 - Confirm the modal
16 - repeat 3, one transfer
17 - Check the item in at branch C
18 - repeat 3, two transfers - one cancelled WrongTransfer, one active
19 - Confirm modal
20 - repeat 3, two transfers
21 - Check item in at branch B
22 - repeat 3, two transfers, one cancelled, one completed
Signed-off-by: Christine Lee <chlee@pascolibraries.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
We need a skip_future_holds flag in item->current_holds to make renewals
act as they did before. There is no need to add it to biblio->current_holds.
Test plan:
Run t/db_dependent/Holds.t
Interface test: Issue a book, place hold on tomorrow, set ConfirmFutureHolds
to 2 days. Verify that renew is not blocked by this hold.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
We were missing POD here.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
Add future item level hold for another branch.
Check in. Confirm and transfer.
Note that without this patch, there is no patron info for the column
On hold for on transferstoreceive.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
- Add a new subscription to a serial notice (with the option 'create an item record' selected)
- Receive one issue and create the linked item
- Return to the bibliographic record
- Edit item - Action - Delete
- Tick the box 'delete serial issues linked to item' and confirm
- The item should still be deleted correctly
- Back to subscription : the issue linked to the item doesn't exist any more
Signed-off-by: Boubacar OUATTARA <boubacar.ouattara@biblibre.com>
Signed-off-by: Nathalie <nathalie.savarit@univ-amu.fr>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Set these sysprefs:
- FinesMode: Calculate and Charge
- WhenLostForgiveFine: Forgive
- WhenLostChargeReplacementFee: Charge
In circ rules:
- Have a rule that charges fines
- Set Refund lost item replacement fee to "Refund lost item charge and charge new overdue fine"
1 - Have/create item with replacement price
2 - Check item out to patron 1, due date in past
3 - Run fines.pl
4 - confirm fines on patron 1
5 - mark item lost
6 - confirm replacement cost generated and fine forgiven on patron 1
7 - check item in
8 - confirm replacement cost forgiven and new fine generated on patron 1
9 - check item out to patron 2, due date in future
10 - check item in
11 - mark item lost (no replacement fee generated because item is not checked out)
12 - in database, update date_due for checkout to patron 2, set to a date in the past
13 - check item in
14 - confirm patron 2 now has a fine
15 - Apply patches, restart all
16 - Repeat test plan with another item and confirm no fine is added for patron 2
Note: At step 12 we're pushing the date_due of the old issue into the past to make date_due<curdate(). In production, this comes up when there are days between steps 10 and 13.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch makes the method return an actual array instead of a
comma-separated string. The API spec is adjusted so it also expects an
array in the response.
Tests are adjusted for the new return value.
To test:
1. Apply this patch
2. Run:
$ ktd --shell
k$ yarn api:bundle
k$ prove t/db_dependent/Koha/Item.t
=> SUCCESS: Tests pass!
3. Sign off :-D
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When IndependentBranches is enabled, canreservefromotherbranches
set to don't allow is also required to prevent non-superlibrarians
from placing holds in other libraries.
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>
When IndependentBranches is enabled and canreservefromotherbranches
is set to don't allow, then non-superlibrarians should not be able to
place holds for other libraries.
Test plan:
1. Appy the patch.
2. In Koha administration > System preferences, set:
- IndependentBranches: Yes
- canreservefromotherbranches: Don't allow
3. In Koha administration > Circulation and fines rules, check that
you have a rule for all patron categories and all item types, with
unlimited holds.
4. Find (or create) a staff patron for a library other than Centerville:
- Change the username and password so you can log in as the
staff patron.
- Add permissions to the staff patron (More > Set permissions):
. Staff access, allows viewing of catalogue in staff interface
. Add, modify and view patron information
. Place and modify holds for patrons
5. Find (or create) a patron with the same home library as the
staff patron in step 4.
6. Find (or create) a record with an item where the home and
current library are the same as the staff patron in step 3 and the
patron in step 5.
7. As a superlibrarian place a hold for the record from step 6
using the patron from step 5:
- If placing a hold for the next available item, the "Pickup at"
dropdown list should list all libraies.
- If placing a hold on a specific item, the dropdown list for the
"Allowed pickup locations" column for each item should also list
all libraries.
- After placing the hold, in the "Existing holds" table, the dropdown
list for each hold in the "Pickup library" column should
also list all libraries.
8. Log out from the staff interface and login with the staff patron
from step 4.
9. Find the record from step 6 and place a hold using the patron from
step 5 - the library dropdown list should be limited to the
item's home library:
- If placing a hold for the next available item, the "Pickup at"
dropdown list should only list the item's home library.
- If placing a hold on a specific item, the dropdown list for the
"Allowed pickup locations" column for each item should also only
list the item's home library.
- After placing the hold, in the "Existing holds" table, the
"Pickup library" column should now only show the item's home
librayr, with no dropdown list.
Signed-off-by: Anni Rajala <anni.rajala@turku.fi>
Signed-off-by: baptiste <baptiste.bayche@inlibro.com>
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;
0. APPLY PATCH, restart_all
1. Go to a record details page (e.g. http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=285)
2. Click the 'Show filters' button above the table
3. Now, at the top of the Status column you should see a dropdown to filter by status
4. You'll have to create several item status to test everything.
5. Add some new items/or change some item status to: DAMAGED, WITHDRAWN, NOTFORLOAN, RESTRICTED, and LOST
6. Test the status filter for each of these statuses, ensuring the work correctly.
7. Create more new items and have some that are checked out, ensure that filter works
8. Put some items into transit and make sure the 'In transit' filter works
9. Put some items on hold, both item and bib level. Make sure the 'On hold' filter works.
10. Turn on the USERecalls system preference and make some recalls, both item and bib level. Make sure the 'Recalled' filter works
11. Create some bundles, make sure the 'In bundle' status works.
12. Also make sure that the available filter is working.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Bug 37334: Correct logic for filtering by in_bundle
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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>
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 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>
This will make it so if acquisition_source is of an existing vendor_id, it'll show the vendor name instead of the id.
If it's not of an existing vendor_id, show the raw value instead.
I'm not 100% happy with this patch as it adds an edge case to Item::strings_map but I believe the only alternative
is to make 952$e Source of acquisition an AV field in the default framework.
Not only that, but this would have to be an AV field of type 'vendors' that'd have to allow to pick from existing vendors (similar to current 'branches').
The above is a ton more work than initial suggestions would imply.
Happy to be proven wrong (in fact, hoping I am).
This is compatible with main Koha only, not backportable to 23.11
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
In some cases, we may want to update an AccountLine that is linked to a
checkout without knowing whether it is a current or old checkout. In
these cases, use the AccountLines ->checkout accessor to ensure we get
the issue_id correctly, regardless of whether it is a current issue or
and old_issue.
This also applies when generating a new AccountLine based on an existing
AccountLine (for example, adding a credit to refund a previously charged
fine)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
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>
"Use of uninitialized value in string eq"
Test plan:
prove t/db_dependent/Koha/Item.t
should return green
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Edit: tidied the tests (tcohen)
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We should store deleted objects as diffs just as we do for modification and item created.
This enhancement will store modification diffs if the action is set to DELETE, and an "original" object is passed in.
Test Plan:
1) Enable CataloguingLog
2) Deletee an item
3) Query the database for the newest action log:
select * from action_logs order by action_id desc limit 1\G
4) Note the diff column is NULL
5) Apply this patch
6) Restart all the things!
7) Delete another item
8) Query the database again
9) Note the diff has been created!
Signed-off-by: Sukhmandeep Benipal <sukhmandeep.benipal@inLibro.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We should store newly created objects as diffs just as we do for modifications.
This enhancement will store modification diffs if the action is set to ADD or CREATE and an "original" object is passed in.
Test Plan:
1) Enable CataloguingLog
2) Create an item
3) Query the database for the newest action log:
select * from action_logs order by action_id desc limit 1\G
4) Note the diff column is NULL
5) Apply this patch
6) Restart all the things!
7) Create another item
8) Query the database again
9) Note the diff has been created!
Signed-off-by: Sukhmandeep Benipal <sukhmandeep.benipal@inLibro.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When modifying bibliographic record, Koha records in the log the
original version of the record. This allows one to see what has been
changed in the record.
However, in case of item modification Koha records in the log the the
current version of the item (i.e. the version after the edit). This is
inconsistent with the biblio modification behavior and makes it
difficult or even impossible to trace changes (especially in case of the
first modif since the initial version is not being recorded).
This patch makes the item modification logging feature work similarly to
logging modifications in bibliographic records.
Test plan:
==========
1. With CataloguingLog enabled (default in ktd) make a modification of
an item.
2. Check the Modification log. You should see as the recorded version
the version of the item after the modification.
3. Apply the patch; restart_all.
4. Repeat p. 1.
5. In the Modification log you should see now the version of the item
that existed before the recent modification.
Sponsored-by: Ignatianum University in Cracow
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Apply patch and restart_all, and yarn api:bundle
2. Check the items endpoint for items.stack ( http://localhost:8081/api/v1/items/144 )
3. The data is there, and correct.
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The API wasn't including the effective_bookable value in responses
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch updates the bookable nature of items to allow setting at the
itemtype level and then overriding that setting at item level should you
so wish to do so.
We also now properly handle the item_level-itypes preference such that
we look at item or biblioitem level appropriately.
Signed-off-by: Esther <esther@bywatersolutions.com>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We need to also exclude cancelled bookings from the find_booking routine
used at checkout.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We need to ensure we handle the new status tracking cancelled/completed
in our clash detection code too.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch allows the return claims endpoint to handle the refunding of a lost fee for the item if the checkbox is checked
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan:
1) Apply patch and reset_all
2) Checkout an item to a patron
3) Mark that item as lost
4) Add a manual invoice for that item's barcode to the patron's account
5) Pay that fine in the Make a payment tab
6) In system preferences, search for NoRefundOnLostFinesPaidAge
7) Set this to -1. I use this value here to avoid needing to go into the database to change the date of the payment we made in step 5. Any fines older than -1 days (i.e. all fines) will be caught by the syspref which is what we want to test)
8) Check in the item
9) The check in message should display "Any lost item fees for this item will remain on the patron's account."
10) Navigate to the Patron's account and confirm that no credit has been added and that the lost fee has therefore not been refunded
11) Run unit test: prove t/db_dependent/Circulation.t
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>
This patch reverts the change to request_transfer, opting to tackle the
StockRotationAdvance requirement to stay in place in ModItemTransfer
itself.
We also add a FIXME to RotatingCollections.. I'll look to removing that
on another bug to reduce the scope of this one.
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>
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>
ModItemTransfer is still very heavy handed and outright overrules
existing transfers in the queue.
For StockrotationAdvance transfers it's important that they remain in
the queue to get actioned later, even if a higher precident transfer is
actions in the interim.
This patch adds a clause to the cancellation call within
request_transfer such that StockrationAdvance transfers are left in tact
for the next time the item is checked in.
Test plan
1) Item is added to stock rotation
2) The cronjob creates a 'StockRotationAdvance' transfer
3) The item is checked in, which initiates the transfer, however, a hold is triggered
4) The hold is confirmed, which replaces the StockRotationAdvance
5) The item is checked out
6) The item is checked in, which initiates the transfer again
7) The item is checked in at it's destination and the StockrotationAdvance transfer
has the proper date arrived date set.
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>
Olli Kautonen
Martin Renvoize
Jonathan Druart
Lucas Gass
Marcel de Rooy
Lari Taskula
Nick Clemens
Tomas Cohen Arazi
Martin Renvoize
Matt Blenkinsop
Hammat Wele
Emily-Rose Francoeur
Koha Development Team
Pedro Amorim
Emily Lamancusa
Kyle M Hall
Janusz Kaczmarek
Paul Derscheid