Introduce a new AllowHoldCheckoutOverride system preference (default 1
to preserve existing behaviour) that lets libraries prevent staff from
overriding held-item blockers at the circulation desk.
When AllowHoldCheckoutOverride is set to 0, CanBookBeIssued still
returns the hold-related keys (RESERVED, RESERVE_WAITING, TRANSFERRED
and PROCESSING) in the confirmation hash, but circ/circulation.pl
promotes them to the impossible hash before rendering the template.
This means no override button appears, and checkout of the held item
is refused outright with a clear message explaining which patron the
hold is for.
Matching entries have been added to the IMPOSSIBLE block of the
circulation template so the blocked-checkout message is meaningful.
This sits alongside the existing Allow*Override family
(AllowTooManyOverride, AllowNotForLoanOverride, AllowHoldPolicyOverride
and AllowRenewalOnHoldOverride) and uses the same staff-only semantics.
Test plan:
1. Set AllowHoldCheckoutOverride=1 (default). Place a waiting hold
for patron A on an item. At /cgi-bin/koha/circ/circulation.pl
attempt to check the item out to patron B: a confirmation dialog
appears with "Check out anyway" override buttons.
2. Set AllowHoldCheckoutOverride=0. Repeat: checkout is refused with
a message stating the item has been waiting for patron A. No
override button is offered.
3. Repeat with pending holds (reserves.found IS NULL), items in
transit and items being processed: each is refused when the
preference is 0 and offered as an overridable confirmation when
the preference is 1.
Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This extends the fix from Bug 37966 to circ/circulation.pl. The original
bug fix addressed circ/renew.pl, where renewing a book on hold with an
empty due date would result in the due date being set to "now" (today).
The same issue occurs in circ/circulation.pl when:
1. Attempting to check out an item that is already checked out to the
same patron (which triggers a renewal)
2. The item has a hold on it, triggering the hold override dialog
3. The librarian overrides the hold without specifying a due date
In this scenario, the renewal would incorrectly set the due date to
today instead of calculating it based on circulation rules.
CHANGES:
1. circ/circulation.pl (lines 550-558)
- Added logic to handle the `renewonholdduedate` parameter when
both RENEW_ISSUE and RESERVED conditions are present
- Follows the same pattern as circ/renew.pl
- If `renewonholdduedate` is empty, passes empty string to AddIssue/
AddRenewal, allowing proper date calculation
2. koha-tmpl/.../circulation.tt (lines 351-356)
- Added "Renewal due date" input field in the hold override dialog
- Only appears when both RESERVED and RENEW_ISSUE are true
- Optional field - if left empty, due date is calculated per
circulation rules
TEST PLAN:
1. Enable the RenewalOnHoldOverride system preference (set to "Allow")
2. Set up a patron, item, and circulation rules:
- Create a patron (or use existing)
- Create an item (or use existing)
- Ensure circulation rules have a renewal period (e.g., 14 days)
3. Create a hold scenario:
- Check out the item to the patron
- Place a title-level hold on the same item (you may need a second
patron or use the same patron depending on your holds rules)
4. Test renewal via circulation.pl:
- Go to Circulation (Home > Circulation)
- Scan the patron's barcode
- Scan the item's barcode (the one that's already checked out with
a hold)
- Observe the hold override dialog appears
5. Test WITHOUT this patch:
- Leave the "Renewal due date" field empty
- Click "Yes, renew"
- BUG: The due date is set to today (same as check-in date)
6. Test WITH this patch:
- Leave the "Renewal due date" field empty
- Click "Yes, renew"
- SUCCESS: The due date is calculated based on circulation rules
(e.g., 14 days from now if that's your renewal period)
7. Test optional due date override:
- Repeat the renewal process
- This time, enter a specific date in "Renewal due date" field
- Click "Yes, renew"
- SUCCESS: The due date is set to your specified date
8. Test SpecifyDueDate preference interaction:
- If SpecifyDueDate is enabled and a due date is set via that
interface, it should take precedence over renewonholdduedate
TECHNICAL NOTES:
The fix ensures that when `renewonholdduedate` is empty (empty string),
it's passed through to AddIssue which then calls AddRenewal. The
improved empty string handling in C4::Circulation (from the follow-up
commit) ensures empty strings are not parsed as "now" but instead
trigger proper date calculation based on circulation rules.
This matches the behavior fixed in circ/renew.pl and provides a
consistent user experience across both circulation interfaces.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
It is possible to renew items for patron who has fines over accepted
limit on renew page or from checkout list. This patch adds confirmation
alerts to these renew actions when patron has fines over
"noissuescharge" syspref.
Test plan:
1. Have patron with checkouts and fines over allowed limit
2. Renew checkouts either from renew page or checkout list
=> renew is successful
3. Apply patch
4. Repeat steps 1 and 2
=> On renew page an alert is displayed and user has to confirm
renew
=> When renew is done from checkout list confirmation pop-up
is displayed
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Shi Yao Wang <shi-yao.wang@inlibro.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch removes the duplicate logging code from the original
Bug 9762 implementation that was not properly removed when the
Alternative implementation was merged.
The original implementation added separate logaction() calls in
CanBookBeIssued and circulation.pl that created additional log
entries with a different JSON format. This caused double logging
when the Alternative implementation (which logs via AddIssue) was
merged on top.
Changes in this patch:
C4/Circulation.pm:
- Removed @message_log array and all pushes to it
- Removed the separate logaction() call at the end of CanBookBeIssued
- Removed 5th return value (@message_log) from CanBookBeIssued
- Removed all if ($issueconfirmed) blocks that were populating @message_log
circ/circulation.pl:
- Removed the problematic line that added OVERRIDDEN to every confirmed
checkout: $needsconfirmation->{'OVERRIDDEN'} = $issueconfirmed
This addresses the double logging issue where circulation overrides
were being logged twice with different formats.
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The $message variable was declared in circ/circulation.pl but never
actually set, making the "No patron matched" template block unreachable.
This is a remnant from old code that was incompletely cleaned when that
functionality was changed/removed.
This patch removes the unused variable, template parameter, and the
unreachable template block.
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
- The message 'No patron matched Restriction overridden temporarily' was appearing on every checkout, even when no restriction override occurred.
- This was caused by the message being set unconditionally after AddIssue in circ/circulation.pl.
- The message should not appear in circulation.pl, but in the Log Viewer.
To test:
1. Check out an item to a patron normally.
2. 'Restriction overridden temporarily' message appears.
3. Apply patches
4. Repeat 1.
---> Verify that no 'Restriction overridden temporarily' message appears.
5. Check out an item that requires an override (e.g., not for loan item with AllowNotForLoanOverride enabled).
---> Verify that no 'Restriction overridden temporarily' message appears.
6. Go to Tool -> Log viewer.
7. Enter the borrowernumber in Object field and submit.
---> Verify that the 'Restriction overridden temporarily' message is logged correctly.
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
1. Create several random patron circ messages with different dates. I used the following sql for my ktd:
-- INSERT INTO messages (borrowernumber, branchcode, message_type, message, message_date)
SELECT
51 AS borrowernumber,
'CPL' AS branchcode,
ELT(FLOOR(1 + (RAND() * 3)), 'L','B','E') AS message_type, -- L=Staff note, B=OPAC, E=Email (adjust to your codes)
CONCAT('Random test message ', FLOOR(RAND()*1000)) AS message,
DATE_ADD(CURDATE(), INTERVAL -FLOOR(RAND() * 1825) DAY) AS message_date -- random day in last ~5 years (5*365)
FROM (
SELECT 1 UNION ALL SELECT 2 UNION ALL SELECT 3 UNION ALL SELECT 4 UNION ALL SELECT 5
UNION ALL SELECT 6 UNION ALL SELECT 7 UNION ALL SELECT 8 UNION ALL SELECT 9 UNION ALL SELECT 10
) AS x;
2. View the patron account and notice that messages are sorted by type, but not by date.
3. Apply the patch and restart_all
4. Refresh the patron account page and clear the browser cache if necessary.
5. View the patron account again and notice that the messages are still sorted by type, but they are also sorted in descending order (newest to oldest).
6. Sign off and have a great day!
Signed-off-by: Jen Tormey <jntormey@dmpl.org>
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>
An alternative approach to the original submission for bug 9762. Instead
of recording a distinct action log line for a set of override messages
in addition to the standard issue record, this patch updates the
existing issue log to include any confirmation or impossible responses
from the preceeding CanBookBeIssued call.
We continue to record these as a JSON structure as the prior patch did,
but instead of human messages we use the predefined codes as returned
from the existing CanBookBeIssued response.
To test:
After each step, a single action log message should be displayed under
`Tools > Log viewer`. The message itself will now consist of a JSON
string with an array of 'confirmations' and 'forced' strings
representing the overriden feedback from CanBookBeIssued.
Circulation -- Checking out
1) Check out an item that is age-restricted (AgeRestrictionOverride syspref)
2) Check out an item that has a “not for loan” status (AllowNotForLoanOverride
syspref)
3) Check out an item that has a “lost” status (IssueLostItem syspref)
4) Check out an item to a patron who has reached the checkout limit
(AllowTooManyOverride syspref)
5) Check out an item to a patron who is not allowed to borrow this item type
6) Check out an item to a patron who has unpaid fines (AllFinesNeedOverride
and/or AllowFineOverride + noissuescharge sysprefs)
7) Check out an item on hold for someone else
8) Check out an item on hold ready for pickup by someone else
9) Check out an item already checked out to someone else
(AutoReturnCheckedOutItems syspref)
10) Check out to a patron who has restrictions
Circulation -- Checking in
11) Ignore a hold upon check in
12) Ignore a hold and transfer upon check in
Circulation – Renewing
13) Renew an item on hold for someone else
(AllowRenewalOnHoldOverride syspref)
14) Renew an item that has reached the maximum number of renewals
(AllowRenewalLimitOverride syspref)
Holds
15) Place a hold for a patron who is not allowed to place this item
type on hold (AllowHoldPolicyOverride syspref)
16) Place a hold for a patron who has reached the maximum number of
holds
17) Place an item-level hold when rules dictate that this is not
allowed
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch allows you to save commands that have been overridden by someone.
The patch has been updated but is not yet completed. Tests 10, 13, 14, and 17 are still not functional. Tests 15 and 16 need to be fixed as they do not display the barcode. All other tests should be functional.
To test:
--After each step, a message will be displayed in the action_logs table and in Tools > Log viewer --
Circulation -- Checking out
1) Check out an item that is age-restricted (AgeRestrictionOverride syspref)
2) Check out an item that has a “not for loan” status (AllowNotForLoanOverride syspref)
3) Check out an item that has a “lost” status (IssueLostItem syspref)
4) Check out an item to a patron who has reached the checkout limit (AllowTooManyOverride syspref)
5) Check out an item to a patron who is not allowed to borrow this item type
6) Check out an item to a patron who has unpaid fines (AllFinesNeedOverride and/or AllowFineOverride + noissuescharge sysprefs)
7) Check out an item on hold for someone else
8) Check out an item on hold ready for pickup by someone else
9) Check out an item already checked out to someone else (AutoReturnCheckedOutItems syspref)
10) Check out to a patron who has restrictions
Circulation -- Checking in
11) Ignore a hold upon check in
12) Ignore a hold and transfer upon check in
Circulation – Renewing
13) Renew an item on hold for someone else (AllowRenewalOnHoldOverride syspref)
14) Renew an item that has reached the maximum number of renewals (AllowRenewalLimitOverride syspref)
Holds
15) Place a hold for a patron who is not allowed to place this item type on hold (AllowHoldPolicyOverride syspref)
16) Place a hold for a patron who has reached the maximum number of holds
17) Place an item-level hold when rules dictate that this is not allowed (In circulation rules put "On shelf holds allowed" to "If any unavailable")
Sponsored-by: Solutions inLibro inc. <https://inlibro.com/>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
It can be useful, for instance, if a library has the same title from
different publishers (so 1 title but several biblio records) but the
user only wants a copy of the book, regardless of the publisher.
Test plan:
0. Run updatedatabase.pl and misc/devel/update_dbix_class_files.pl
1. Go to intranet search, display some results, click on some checkboxes
and click on 'Place hold' button at the top of the results.
2. Search for a patron
3. Check the 'Treat as hold group' checkbox
4. Click on 'Place hold'
5. In the next screen you should see all the holds you placed with the
additional text '(part of a hold group)' in Details column.
6. Click on the "hold group" link. A modal window should appear with
the content of the hold group (a list of holds)
7. Check in an item of one of the reserved biblios and confirm the hold
8. The hold status is changed to Waiting, and all other holds are deleted.
The other holds will also be removed from the holds queue.
9. Confirm tests pass
- t/db_dependent/Koha/Holds.t
- t/db_dependent/Reserves/HoldGroup.t
Note: the "hold group" link is displayed in the following pages:
- reserve/request.pl
- circ/circulation.pl
- members/moremember.pl
- circ/pendingreserves.pl
- circ/view_holdsqueue.pl
Note: A hold group is counted as only one hold
Sponsored-by: Catalyst IT
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When displaying messages on a patron account, group the messages by
type and label which are OPAC messages and which are internal staff
messages.
To test:
1. Find a patron and add several messages to their account, alternating
between internal staff messages and OPAC messages
--> Note that the messages display in the order that they are added and
not explicitly labeled
2. Apply patch and refresh page
--> Confirm that all staff messages display first and all OPAC messages
display underneath
--> Confirm that messages are now labeled "Staff note" or "OPAC"
3. Play around on the patron account and confirm that the message
display is consistent after taking different actions:
- On the Details page
- On the Check out page
- After adding a new staff message
- After adding a new OPAC message
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1 - Create a patron in a category that can be a guarantee and do not assign any guarantor
2 - Create a patron in a 'Child' account type and do not assign a guarantor
3 - Enable system preference 'ChildNeedsGuarantor'
4 - View 'Check out' and 'Details' tabs for both patrons, note there is no warning
5 - Apply patch
6 - Repeat 4, note warning on all pages
7 - Add a patron gaurantor on the child - repeat 4 - warning is gone
8 - Add non-patron guarantor information to other patron - repeat 4 - warning is gone
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>
The first motivation of this patch is to remove the following warnings
from t/db_dependent/Auth.t:
Use of uninitialized value $anonymous_patron in string eq at /kohadevbox/koha/C4/Auth.pm line 1497
Actually a correct fix seems to add a new `is_anonymous` method to
Koha::Patron in order to remove the warnings from everywhere else.
Test plan:
Confirm that you cannot log in using the anonymous patron and that the 2
tests are passing
prove t/db_dependent/Auth.t t/db_dependent/Koha/Patron.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1. Put a few items on hold and make note of the barcodes.
2. Check out one of the items to a patron who doesn't have the hold
3. Check the cancel hold radio button
4. Also check the Remember for the session for this patron
5. Click 'Yes, check out'
6. Notice the item is checked out and the hold is cancelled
7. No checkout another on hold item to the same patron
8. No confirm screen ( good )
9. The item is checked out ( good )
10. The hold is not cancelled. ( bad )
11. APPLY PATCH and restart all
12. Try steps 1 - 9 again. This time the 2nd hold should be cancelled.
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>
Update the patch to use Koha::Account and it's associated 'outstanding'
methods to ensure we accurately portray outstanding amounts rather than
'all credits' totals.
I also remove the unused `$balance` variable from the
members/moremember.pl controller.
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>
To test:
1: Have patrons with a variety of credit/debit combinations
2: Confirm Koha shows the total debit amount in patron_messages if any debits exist
3: Confirm Koha does not show anything about creditd in patron_messages if any debits exist
4: Apply patch, restart_all
5: Confirm all patrons show both debit total and credit total
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
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>
To test:
1. Set up sysprefs:
- Set any non-empty value for ClaimReturnedLostValue
- Set AutoClaimReturnStatusOnCheckout to "found in library"
- Set AutoClaimReturnStatusOnCheckin to "returned by patron"
2. Check out an item to a patron
3. On the patron's account page, click the "Claim Return" button next to
that checkout
4. Check the item in. Note the message that the claim was auto-resolved.
5. Return to the patron's account page and open the Claims Returned tab
--> Note that the claim is resolved and hidden
6. Click the "Show all 1 claims" link to view the hidden claim. Make a
note of the resolution code and timestamp.
7. Check the item out again
--> Note the message saying that the claim was resolved, even though it
was already resolved previously
8. View the return claim again
--> Note that the timestamp and resolution code have changed
9. Apply patch and restart_all
10. Repeat steps 2-8 with a new item
--> Note you do not get a claim resolved message on checkout this time
--> Note that the timestamp and resolution code remain the same before
and after the checkout
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This fixes an internal server error when renewing an expired
child patron without a guarantor, when the ChildNeedsGuarantor
is set to "must have".
Test plan:
1. Create or edit a child patron:
- Don't add a guarantor.
- Set the "Expiry date" to a date in the past.
2. Set the ChildNeedsGuarantor system preference to "must have".
3. Refresh or view the patron's check out or details page, and
select the "Renew" link under the attention heading -
this generates an internal server error message.
4. Apply patch.
5. Repeat step 3, you will now get a standard error message
"This patron could not be renewed: they need a guarantor."
6. Add a guarantor for the patron.
7. Repeat step 3, and click "Renew" - the patron is now renewed.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
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>
There are large blocks of code in circulation.pl that are incorrectly indented. This means any new code placed within those blocks fails the QA tests as it automatically adds new untidy lines. This patch tidies the file to remove this issue and start from a clean position in terms of tidyness.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds functionality that will remember whether an action has been confirmed for a particular patron for the session. While carrying out an action on that patron, if the same checkout confirmation message keeps appearing the user can now select to remember their confirmation while they are still working on that patron. When the user moves onto a new patron the confirmations then reset and accumulate again for the new patron.
Test plan:
We're going to use rental fees as the example to prompt the checkout confirmation dialog. If you wish to use something else to test then feel free, it should work the same. Do not use patron debts though, as we already track a confirmation for this elsewhere and the test plan will appear to fail when in fact it is behaving as expected
1) In system preferences set RentalFeesCheckoutConfirmation to 'ask'
2) Choose a patron and checkout an item to that patron that incurrs a rental charge (in KTD this will be any item that does not have an itype of 'BK', 'REF' or 'VM'
3) A dialog should display asking you to confirm the checkout.
4) There should be a checkbox on the dialog to "Remember for the session for this patron"
5) Click Yes, checkout out without checking this checkbox
6) Select another item and checkout - the dialog should display again
7) This time, check the checkbox and click Yes, check out
8) Checkout another item (depending on your fines limit settings, you may need to pay the rental charges before the system will allow you to checkout again so go ahead and do this)
9) This time the dialog should not appear as the system has remembered our confirmation for this patron for the session
10) Choose a new patron
11) Repeat steps 2 - 9
12) It should work as outlined above
13) Sign off!
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
QA tool failed because the previous patch added one line to a large
block of code that was incorrectly indented. Fixed the indentation
separately on this patch.
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Set up sysprefs:
- Set any non-empty value for ClaimReturnedLostValue
- Set AutoClaimReturnStatusOnCheckout to "found in library"
- Set AutoClaimReturnStatusOnCheckin to "returned by patron"
2. Check out an item to a patron
3. On the patron's account page, click the "Claim Return" button next to
that checkout
4. Check the item in. Note the message that the claim was auto-resolved.
5. Return to the patron's account page and open the Claims Returned tab
--> Note that the claim is resolved and hidden
6. Click the "Show all 1 claims" link to view the hidden claim. Make a
note of the resolution code and timestamp.
7. Check the item out again
--> Note the message saying that the claim was resolved, even though it
was already resolved previously
8. View the return claim again
--> Note that the timestamp and resolution code have changed
9. Apply patch and restart_all
10. Repeat steps 2-8 with a new item
--> Note you do not get a claim resolved message on checkout this time
--> Note that the timestamp and resolution code remain the same before
and after the checkout
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Create a Statistical Patron
2. Set BlockReturnOfLostItems to Block.
3.. Mark an item as lost
4. Check it out to the Statistical Patron. You should see the message "Item was lost, cannot be returned."
5. Set BlockReturnOfWithdrawnItems to Block.
6. Mark an item as withdrawn
7. Check it out to the Statistical Patron. You should see the message "Item was withdrawn, cannot be returned."
8. Turn off BlockReturnOfWithdrawnItems, check out the same item to the Statistical Patron. You should see a message "Item was withdrawn."
9. Place an item on hold.
10. Check it out to the Statistical Patron
11. See the message "Item on hold, please checkin."
12. Make sure ClaimReturnedLostValue is set to a lost value
13. Claim a return, making sure it is not still checked out to the patron
14. Checkit it out to the Statistical Patron.
15. See the message "Item claimed returned, please checkin."
16. Have an item on a regular patron account that has been recalled.
17. Checkit it out to the Statistical Patron.
18. See the message "Item can fill a recall, please checkin."
Signed-off-by: Kelly <kelly@bywatersolutions.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch ensures we catch checkouts that would interfer with the
preparation period set for an existing booking by adding said period to
the bookings search.
We also reduce the proposed due date for the checkout to be confirmed by
the preparation period for the item.
Test plan
1) Set a booking preparation period for an itemtype
2) Add a booking for an item with that itemtype to fall beyond the due
date that the item would be assigned if you were to check it out now
to your test user, but within the number of days you've set for your
preparation period.
3) Attempt to check the item out to your test user.
4) Note that we catch the booking and warn and that the latest return
date suggested take the preparation period into account.
Sponsored-by: Cuyahoga County Public Library <https://cuyahogalibrary.org/>
Signed-off-by: Kristi Krueger <KKRUEGER@cuyahogalibrary.org>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Sponsored-by: Cuyahoga County Public Library <https://cuyahogalibrary.org/>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Sponsored-by: Cuyahoga County Public Library <https://cuyahogalibrary.org/>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch updates all instances where the current noissuescharge sysprefs are used. They will now use the is_patron_inside_charge_limits method to handle the patron category level limits
Sponsored-by: Cuyahoga County Public Library <https://cuyahogalibrary.org/>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch updates the changed code to set the logged in librarian as
the person who resolved the return claim at checkin/checkout action.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We're actioning the change of claim status outside of any block that
checks the $item exists. As such we'll want to add that check in here.
I did consider that this should live inside AddIssue, but on reflection
the librarian may want to not proceed with the issue given other return
values from the CanBookBeIssued call, but you still want the
AutoClaimReturn to fire regardless as you've now found the item.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
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>
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>
Bug 31422 added a warning message when library limitations issue in patron edition page.
We should add this patron's messages in circ and details pages.
Like age limitations.
Test plan:
1) User's login branch and home library is: Centerville
2) Patron category "B - Board" is limited to Franklin
3) Edit a patron with Board category from Centerville
4) A message appears "The patron's current category (Board) is limited to other libraries."
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Bug 35518 moved some code blocks to after the call to
get_user_and_template() so that userenv would be populated before it
was needed. This caused a couple variables to be set before the
AutoSwitchPatron block could prevent them from being set. Which broke
AutoSwitchPatron functionality. This clears two variable so that
AuthSwitchPatron works again.
The AutoSwitchPatron clears the $borrowernumber variable to switch
patrons. With the AuthSwitchPatron block moved, the $patron variable
still gets set, and the patron doesn't get switched. The clears the
$patron variable too.
Also clear the barcode list.
The AutoSwitchPatron block got moved, and now the @$barcodes variable
gets filled and not cleared. Leading to a 'Barcode not found' error
when the patron is auto switched.
Test plan:
1. Ensure AutoSwitchPatron is turned on.
2. Select the card number of two patron accounts.
3. Find the first patron in circulation.
4. Enter the second patron's card number in the item barcode field to
switch patrons.
5. Observe the error about item barcode not existing, and the patron did
not switch.
6. Apply patch and restart services.
7. Enter the second patron's card number in the item barcode field
again.
8. Observe that the patron was switched with no error about an invalid
barcode.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kelly <kelly@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When there are holds waiting for patrons, sometimes the librarian misses
the "Holds waiting here" display. This patch adds a modal popup warning
when checking out an item for a patron with waiting holds.
Test plan:
1) find a user (user1)
2) find a biblio (biblio1)
3) add a hold for biblio1 to user1
(search biblio1 > Holds > find user1 > Place hold)
4) checkout biblio1 to another user if not already checked out
and checkin through circulation page (not through the user page)
> confirm hold
5) there should be a "Holds waiting here (1)" section added on user1 page
6) checkout any items that isn't the one on hold for user1
-> notice it just checks out as normal
7) apply patch and update database
8) go to administration > system preferences > switch "WaitingNotifyAtCheckout" to "Notify"
9) refresh page and redo step 6
-> notice there is now a modal to warn the librarian of a waiting hold
click Ok to proceed with the checkout, click outside the modal to not do anything
10) additionnally, the popup shouldn't appear if we checkout any of
user1's waiting hold
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Mia Kujala <mia.kujala@xamk.fi>
Signed-off-by: Kelly <kelly@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
There should be no change in beahavior. Following the test plan from Bug 35840.
To test:
1. APPLY PATCH, restart_all
2. Turn on RecordLocalUseOnReturn
3. Create a Statistical patron.
4. Check an item out to a regular patron.
5. Check the item out to a Statistical patron.
6. This should trigger a return and you will see 2 entries in the statistics table, one for localuse and one for a return.
7. Try checking out an item to the Stats patron that is NOT checked out.
8. You should only see 1 entry, localuse, in the statistics table.
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 fixes a mistake in the circulation controller such that the
proper reduceddue date is passed to the template when a checkout would
overlap with a booking.
I also take the oportunity to enhance the functionality to allow
librarians to set their own reduceddue date between now and the hard
reduceddue as required for the existing booking.
Test plan
1) Set an item to 'bookable'
2) Add a booking to that item for user A for a few days time.
3) Attempt to checkout the item to user B and note the warning that
the item is booked for another user.
4) With the patch applied, a reduced due date of 1 day prior to the
booking should be defaulted to in the displayed date picker.
5) You should be able to select any date between today and the day
before the booking starts
6) Confirm you can checkout with the reduceddue date set.
7) Bonus point, confirm the field is required, so if you try to wipe it
and then checkout, you will be blocked.
Signed-off-by: Kelly <kelly@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We do not longer need to generate_csrf from pl files
TODO - members/boraccount.tt and sco/sco-main.tt needs to be adjusted
Bug 34478: [TO SQUASH] Remove generate_csrf from pl
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Currently we get the userenv before we have set it correctly for the session
To test:
1 - Sign in as a user with fast cataloging permission
2 - Bring up a patron, type gibberish into barcode field to get a fast cataloging link
3 - Check the link, it should have your current signed in barcode
4 - Sign in to a different browser with a different user and at a different branch
5 - Bring up a aptron in circulation and type gibberish into barcode field to get a fast cataloging link
6 - It may have your branch, but it may also have the other user's branch from the other window
7 - Keep entering gibberish to get a link until one user has the correct branch
8 - Then switch to the other browser, and keep entering gibberish, watch the branchcode change
9 - Apply patch, restart all
10 - Test switching between browsers. generating fast cataloging links
11 - Users should now consistently have the correct branch
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Pedro Amorim
Martin Renvoize
Emmi Takkinen
Hammat Wele
Laura_Escamilla
Nick Clemens
Tomas Cohen Arazi
Matthias Le Gac
emilyrose
Aleisha Amohia
Emily Lamancusa
Jonathan Druart
Lucas Gass
Andrew Fuerste Henry
Baptiste Wojtkowski
Andrii Nugged
Matt Blenkinsop
Martin Renvoize
Fridolin Somers
Michael Hafen
Shi Yao Wang