The automatic_renewals.pl cron script currently loops through items for automatic renewal and calls the indexer for each one individually. skip_record_index has now been added as a parameter to the AddRenewal function to skip the indexing process. The item numbers are now added to an array and then the indexer is called once from within automatic_renewals.pl and passed the array to queue one indexing job instead of multiple jobs.
Test plan:
1) AddRenewal uses Koha::Items->store() to trigger the indexing process. Run prove -vv t/db_dependent/Koha/SearchEngine/Indexer.t and check tests 5,6,29,30. These tests prove whether passing skip_record_index to store() triggers or skips the indexing process. All four tests should pass to show that skip_index_records can prevent the indexing being triggered.
2) Add multiple renewals that are able to be autorenewed and run the automatic_renewals.pl script. There should be multiple items queued in zebraqueue.
3) Apply patch and try again
4) There should now only be one job queued in zebraqueue
Mentored-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We currently have syspref UpdateNotForLoanStatusOnCheckin which updates
notforloan status when item is checked in. We should also have
same kind of syspref for check outs. This would be usefull if for
example library has item in exhibition with status
"In exhibition, available for loan". When patron check outs the
item notforloan status can be reseted back to 0, informing staff
that the item is back on circulation.
This patch adds new syspref Add syspref UpdateNotForLoanStatusOnCheckout.
To test:
1. Set items notforloan status as e.g -1.
2. Check out item for a patron.
=> Note that items status doesn't change.
3. Apply patch and update database if needed.
4. Add "-1: 0" to syspref UpdateNotForLoanStatusOnCheckout.
5. Check item in and out again for a patron.
=> Note that items status is changed as 0.
Also prove t/db_dependent/Circulation/issue.t
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Catrina <catrina@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch updates the enque method in C4::Message to expect a
Koha::Patron object in the parameters and then uses that patron object
to select the correct email address for notices as defined by
AutoEmailPrimaryAddress.
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lisette Scheer <lisetteslatah@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch ensures a record is indexed only after the renewal transaction
has completed successfully. Otherwise the job cannot be found by the background process
worker, becaue it was not yet in the DB
To test:
1 - Make sure you are using ES, and the es indexer is running
2 - tail -f /var/log/koha/kohadev/*.log
3 - Issue an item to a patron and renew it
4 - Note error in es-indexer-output.log like:
[2023/03/21 12:22:36] [WARN] No job found for id=157 main:: /kohadevbox/koha/misc/workers/es_indexer_daemon.pl (129)
5 - Apply patch
6 - Renew again
7 There should be no error
8 - Search for the record and confirm items info displays correctly
9 - View the background jobs in admin, confirm the most recent job has completed
Signed-off-by: Janusz Kaczmarek <januszop@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch filters out non_priorty holds in the on_reserve condition.
Test plan
1) Run t/db_dependant/Holds.t
2) Note it fails without this patch
3) Apply patch
4) Re-run the above test, note it now passes
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
introduced in:
73c3c5d2f1
Bug 31112: (QA follow-up) Reduce database queries
started from:
8ba1a9a534
Bug 31112: Remove unnecessary if-clause
Currently, you can renew the item even if someone already made an item level
hold on that item. This patch changes that, making it not possible to do so.
To reproduce:
1. Checkout an item, and make another item level hold on that specific item.
2. Renew it using the "Renew" checkbox, it should get renewed without any problems.
3. Apply the patch.
4. Checkbox should be gone and replaced with "On Hold" link that leads to the hold that doesn't allow you to renew the item again.
5. "Renew all" button should not work either.
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1. Create a statistical patron and checkout, checkin to them.
2. Notice in the statistics table that the location is NULL
3. Apply patch
4. Try steps 1-2 again
5. The location should be correctly recorded in statistics.location
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch makes the renewal_type an enum, to match the change on the
DB. A test is added to account the fact the API is always setting
'Manual' request type.
Bonus: small portion of code gets a tidy, should've been asked by QA.
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>
Edit: Kyle, stop impersonating John Doe
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
A requirement has been requested to record whether a renewal was done manually or automatically. A column has been added to the checkout_renewals table in the database to record this and a check is now in place to determine whether the renewal was manual or automatic. The API has also been updated to reflect this new column and return the data when requested. The renewals modal view has also been updated to show what type the renewal was.
Test plan:
1) In the database shell run "show columns from checkout_renewals;" and observe that there is currently no column for recording the type of renewal
2) Apply patch
3) In the shell run "dbic" and "perl installer/data/mysql/updatedatabase.pl" to update the database schema with the new column.
4) Create some checkouts
5) Renew some checkouts manually and observe in the database that there is now a column called "renewal_type" that will have recorded these as "Manual"
6) Create some checkouts that can be automatically renewed
7) Run the cron script in automatic_renewals.pl and observe that there are now also entries with a renewal_type of "Automatic"
8) Send a GET request to http://localhost:8081/api/v1/checkouts/1/renewals and observe that the renewal_type is now returned in the response
9) In the Item Details tab for a record, there is the "Current renewals" option which has a button to view renewals. Click on this and observe that the modal now displays the new information.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch removes GetDebarments from Circulation.pm replacing them with
calls to $patron->restrictions and filtering using a chained search
call.
Test plan
1. Confirm that t/db_dependant/Circulation.t continues to pass
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Currently this syspref only bokcs the literal 'return' from a patron, i.e. the checkin
It still processes transfers, refunds lost items, updates NotForLoan status etc.
We should block all of these things
To test:
1 - Set BlockReturnOfWithdrawn to block
2 - Set an item as lost and withdrawn
3 - Check it in
4 - Item is found
5 - Apply patch
6 - Repeat 1-3
7 - Checkin is blocked, item still lost
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
Before
1) Select a user with active indefinite or definite restrictions (manual restriction works)
2) Make sure finedays=0 for the user category. See [1]
3) Checkout and return an item (not overdue)
A previous restriction reminder will appear
4) Checkout and return an overdue item (change the date at checkout)
No previous restriction reminder will appear
After applying patch:
Same steps, but a reminder should appear for step 4)
[1] The "finedays" setting is called "Suspension in days" in the web interface, if you're searching for it like I did...
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
When one tries to check out item which has hold in it,
"Please confirm checkout" message uses patrons home library
instead of holds pick up library. It would be more logical
to use latter here.
To test:
1. Find record with holds.
2. For first priority hold, change it's pick up library to differ from patrons homebranch if needed.
3. Check out records item for a different patron.
=> Note that notice reads: "Item ... has been on hold for ... at [patrons homebranch] since ...".
4. Apply this patch.
5. Repeat steps 2 and 3.
=> Notice should now read: "Item ... has been on hold for ... at [holds pick up branch] since ...".
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Axelle Clarisse <axelle.clarisse@univ-amu.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch makes three changes:
1 - The borrower's own holds are not counted towards HighHolds limit
2 - We exclude all hold counts from CanItemBeReserved
3 - Static mode should only decrease hold when over the decreaseLoanHighHoldsValue, not when equal
Previously a patron's hold could put the count over the threshhold, and
if the patron is only allowed 1 hold per record, and the hold wasn't found before
the checkout, it would make all items unholdable, thus lowering the theshhold for
dynamic HighHolds
To test:
1 - Set sysaprefs:
decreaseLoanHighHolds - enable
decreaseLoanHighHoldsDuration - 1
decreaseLoanHighHoldsValue - 1
decreaseLoanHighHoldsControl - "over the number of holdable items on the record" / dynamic
decreaseLoanHighHoldsIgnoreStatuses - blank
2 - Set circ rules to allow 1 hold per record and loan period of 5
3 - Find/create a record with 3 items
4 - Place a title level hold for two different patrons
5 - Attempt to checkout item - note warning about high holds
6 - Cancel checkout
7 - Set decreaseLoanHighHoldsControl - "on the record" / static
8 - Attempt checkout - note warning about high holds
9 - Apply patch
10 - Checkout item - no warning
11 - checkin item, replace hold
12 - Set decreaseLoanHighHoldsControl - "over the number of holdable items on the record" / dynamic
13 - Checkout item - no warning
14 - prove t/db_dependent/DecreaseLoanHighHolds.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The TooMany() function and fine calculation functions were incorrectly
hard coded to use homebranch for fetching the circulation rules. Those
ignored completely the syspref HomeOrHoldingBranch where the user
might have set it to holdingbranch and therefore the fines and whether
patron has too many checkouts (TooMany()) were counted using the
unintended branch's rules. This problem only arises in the cases where
there are branch specific circulation rules defined.
Test plan:
1. Make sure following tests pass:
$ prove t/db_dependent/Circulation/_CalculateAndUpdateFine.t
$ prove t/db_dependent/Circulation/TooMany.t
Test plan for fines.pl:
1. Add branch specific fine rules for branches A and B. A having a
fine of 1 per day and B having a fine of 0 per day.
2. Set sysprefs:
CircControl = the library the items is from
finesMode = Calculate and charge
HomeOrHoldingBranch = holdingbranch
3. Create an item with home and holding branch of A
4. Checkout the item with a due date in the past (the past due date can be
specified by clicking "Checkout settings" in the checkout page) and
make sure the branch you are checking from is B.
5. Run perl /usr/share/koha/bin/cronjobs/fines.pl
6. Notice that fines have popped up now to the patron incorrectly
7. Apply patch
8. Pay fines, Check-in the item and check it out again
9. Run perl /usr/share/koha/bin/cronjobs/fines.pl
10. Notice that fine is now 0. This means that the branch
B (holdingbranch of the checked-out item) specific rule is used.
Test plan for staticfines.pl:
1. Add branch specific fine rules for branches A and B. A having a
fine of 1 per day and B having a fine of 0 per day.
2. Set sysprefs:
CircControl = the library the items is from
finesMode = Calculate and charge
HomeOrHoldingBranch = holdingbranch
3. Create an item with homebranch A and holding branch of A
4. Checkout the item with a due date in the past (the past due date can be
specified by clicking "Checkout settings" in the checkout page) and
make sure the branch you are checking from is B.
5. Run perl staticfines.pl --library A --library B --category <PATRONS_CATEGORYCODE>
and notice that now there is inccorectly fines
6. Apply patch
7. Pay fines, Check-in the item and check it out again
8. Run perl staticfines.pl --library A --library B --category <PATRONS_CATEGORYCODE>
and notice the fines are now not generated
Rebased-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Petro Vashchuk <stalkernoid@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This can be used to instruct staff how the item should handled when
it's checked in. For example items notforloan status has been
changed as "Invoiced item" while item has been on loan. When it's
checked in staff sees that they should put item aside for further
processing.
To test:
1. Apply patch and update database if needed
2. Set items notforloan status as -1 (or create new one)
3. Add line "-1: ONLYMESSAGE" to UpdateNotForLoanStatusOnCheckin
4. Check item out for patron.
5. Check item in.
=> Description of notforloan status should be displayed.
=> Confirm notforloan status hasn't changed.
Also prove t/db_dependent/Circulation/issue.t
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
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>
The POD had $issue in the example, but $checkout in
explanation. Also standardized a bit of other terminology.
(borrower, issue) = (patron, checkout)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The question whether item is denied renewal doesn't depend on
circulation rules or the patron, it is only a property of the item and
only changes to the item's attributes can cause the return value of
the check to change, thus we should move this to be a method of
Koha::Item.
To test:
1) Run unit tests
$ prove t/db_dependent/Circulation.t
$ prove t/db_dependent/Koha/Item.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Lets stick to standard terminology and use categorycode rather than
usercode here.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch populates the koha.statistics.usercode with borrowers.categorycode where it is easily available.
Currently for statistics.type 'issue' OR 'localuse' OR 'renew'.
Supplied a script to UPDATE the old statistics records.
Have fun!
To test:
1. Add loan for patron.
2. Check statistics table
=> 'usercode' column for this issue should now contain patrons categorycode
To test add_statistics_borrowers_categorycode.pl:
1. Run add_statistics_borrowers_categorycode.pl
2. Check statistics table
=> all statistics which are type 'issue' OR 'localuse' OR 'renew'
should now contain patrons categorycode in 'usercode' column
Also prove that tests in t/db_dependent/Circulation.t still pass.
Rebased-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adjusts the code that uses GetOpenIssue to use/find a Koha::Checkout object
instead
To test:
1 - Add a course to course reserves
2 - Create an item with barcode TESTKOC
3 - Add the item to a course
4 - Checkout the item
5 - View course details on stff and opac and confirm item shows as checked out and due date displays
6 - prove t/db_dependent/Circulation/issue.t t/db_dependent/Circulation.t t/db_dependent/CourseReserves.t
7 - Browse to Circulation->Upload offline circulation
8 - Upload a file to return the item: https://wiki.koha-community.org/wiki/Koha_offline_circulation_file_format
9 - Confirm item is returned
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
It's possible that there could be 0 possible reserves, for example
when the hold has already been filled, thus the check would fail as
the item count can never be less than 0.
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Before the changes from bug 31112 when CheckReserves returned a
non-priority hold we didn't return "on_reserve" status but checked in
addition to that whether there are any priority holds and if there
were, only then we returned the "on_reserve" error.
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Previously we fetched all in a single call using biblionumbers
Fetching each individually could be a performance hit on systems
with large numbers of holds
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We now count all holds for all patrons, we can still eject if we have more
holds than we do items
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If a single patron had more than 1 hold to a biblio and there was only one
available item we allowed incorrectly renewing the checkout when
AllowRenewalIfOtherItemsAvailable was set to "Allow". This
changes CanBookBeRenewed so that it makes sure all the holds are
filled and not just one per patron.
To test:
1) prove t/db_dependent/Circulation.t
2) (Optional, as unit test is provided)
- Set AllowRenewalIfOtherItemsAvailable = Allow
- Create biblio with three items
- Checkout one item to patron A
- Add two biblio-level holds for patron B
- Try to renew patron A's checkout with and without this patch.
- Notice that without this patch the renewal succeeds even though we
one unfilled hold left. After applying the patch the renewal should
fail.
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1) Please check manually that the logic stays the same, use git's -w command line parameter to
ignore whitespace changes in the diff output.
2) prove t/db_dependent/Circulation.t
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch handles the final removal of GetTransfers from
C4::Circulation.
Test plan
1/ Check that there is no mention of the GetTransfers method codebase
wide now
2/ Run the circulation and transfers tests and check nothing fails..
perhaps even run the full test suit in k-t-d
3/ Signoff
Rebased-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.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@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This was a test added by the following commit:
commit 99eccc18ed
Date: Thu Jun 16 10:10:09 2011 +0100
Bug 5549 : Handle datetimes on return
It's no longer needed now, we can pass a DateTime or an ISO-formatted
date
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>
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>
There are 5 fields that are not set if no value is provided when saving/editing a rule in Administration->Circulation and fines rules
- issuelength
- hardduedate
- unseenrenewalsallowed
- rentaldiscount
- decreaseloanholds
This is problematic because it gives the impression these rules are set as blank, but in reality they don't exist and the rule will fal back to the higher level
To test:
1 - Set a rule for
Patron category: Teacher
Itemtype: All
Hard due date: (Today)
Lona period: 10
2 - Set a rule for
Patron category: Teacher
Itemtype: Books
Hard due date: (leave blank)
Loan period: 10
3 - Expected behaviour is Book item will checkout to teacher for 10 days, all other types will be due yesterday at 25:59:00
4 - Checkout an non-book item type to teacher
5 - Hard due date applies
6 - Checkout a 'book' item type to teacher
7 - Hard due date applies - FAIL
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If the rule renewalperiod is the blank empty string instead of being null/undefined or non-existant, Koha will interpret the renewal period as being zero days instead of falling back to the issuelength rule.
It makes sense to me that a literal 0 here should make it renew for zero days even though that is nonsensical.
Test Plan:
1) Delete all your rules
2) Create an all/all/all rules with an empty string for renewal base
period
3) Note that renewing an item does nothing
4) Apply this patch
5) Restart all the things!
6) Renew again
7) Note the renewal uses the issuelength rule as intended
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.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>
This patch fixes some unit tests by ensureing we set a valid userid for
mock userenv setting so that the foreign key constraint doesn't fail and
it also removes the exception class and check for renewer_id from the
store method as, for example with autorenewals, the renewal may not have
been triggered by a actual user.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch performs the following column renames:
* id => renewal_id
* issue_id => checkout_id
The idea is that no translation is needed for the API, and also, being a
new table, we can educate the users into the 'to be' terminology we are
leaning towards, instead of having them learn one naming to create
reports and then need to translate them once we normalize things in a
future.
That said, this is simple to review.
Apply this patch and repeat the test plan.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Rename the issues.renewals field to renewals_count to prevent a method
name collision with the new relation accessor introduced by this
patchset.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The Swedish Libris ILL backend lets librarians store a specific due date
when an ILL loan is received.
This patch set adds a new date_due column to the illrequets table that can be
used by the different backends to store a due date. If an illrequest has the
date due set, it will be used when the item is checked out instead of the calculation
using the circulation conditions.
To test:
- Apply the patch and make sure the atomic database update is run
- Use the FreeForm backend to add one ILL request. Take note of the
illrequest_id of the request you created. We refer to this as
"x" below.
- Connect a biblio (with biblionumber y), that has an item with a
barcode, to the ILL request directly in the database:
UPDATE illrequests SET biblio_id = y WHERE illrequest_id = x;
- Next we set the due date, this would normally be done by or from the backend.
UPDATE illrequests SET date_due = "2023-01-01" WHERE illrequest_id = x;
- Go to circulation and issue the barcode of the item to the
patron associated with the FreeForm ILL request. Verify that the
loan gets a due date of 2023-01-01.
- Ideally: return the item and issue it again through SIP2 and SCO,
and verify that the due date is still 2023-01-01.
- Verify that there are no regressions, so that regular calculation
of due dates still work.
- prove t/db_dependent/Circulation.t
(Patch description, test plan and partial code credits to Magnus Enger)
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
(Patch description and test plan rewritten to reflect changes in development)
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
