Koha::Calendar is, by construction, a per-library object — it croaks
without a branchcode argument and every method is branch-scoped. The
top-level namespace hides that. Move the whole tree under
Koha::Library::Calendar to match the actual semantics, the existing
/libraries/{library_id}/calendar REST routes, and the established
Koha::Library::* convention (Group, Hour, FloatLimit, OverDriveInfo).
This commit:
- renames the Koha::Calendar(::*) tree to Koha::Library::Calendar(::*)
- updates package declarations, POD and internal 'use' statements
within the moved tree
- updates the four DBIC Schema Result overrides (koha_object_class /
koha_objects_class) to the new namespace
- updates callers inside C4::* modules (Calendar, Circulation,
Reserves, Overdues, HoldsQueue), Koha::{Patron,Hold,Checkouts,
CurbsidePickup}, circ/returns.pl, the installer and cronjobs
- updates the 42310-owned tests (Calendar tests, HoldsQueue.t,
Holds/WaitingReserves.t, Holidays.t, Koha/CurbsidePickups.t,
Reserves/CancelExpiredReserves.t and the libraries.t CRUD block)
Koha::Library->calendar, the REST controllers and the 42311 tests
are updated in separate follow-up commits under their respective
bugs.
Test plan:
- prove t/db_dependent/Koha/Library/Calendar.t
- prove t/db_dependent/Calendar.t
- prove t/db_dependent/Holidays.t t/db_dependent/HoldsQueue.t
- prove t/db_dependent/Holds/WaitingReserves.t
- prove t/db_dependent/Reserves/CancelExpiredReserves.t
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
When AllowFineOverride is disabled and NoIssuesChargeLinkedAccounts
is exceeded, hide the barcode field and show 'Cannot check out'.
Signed-off-by: Trevor Diamond <trevor.diamond@mainlib.org>
Signed-off-by: Kellie Stephens <kellie.stephens@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Enable linked patrons to pick up each other's holds when allowed.
Signed-off-by: Trevor Diamond <trevor.diamond@mainlib.org>
Signed-off-by: Kellie Stephens <kellie.stephens@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Updates circ/transferstoreceive.pl to use the new REST API with
an ajax DataTable to display transfer to receive.
Test Plan:
1) Apply this patch
2) Restart all the things!
3) Set an item in transit to your logged in library ( check it in at another
branch so it is sent home, or place a hold to trigger a transfer )
4) Place a hold on a second transferred item, and a recall on a third
5) Browse to /cgi-bin/koha/circ/transferstoreceive.pl
6) Note the "On hold for" column shows the hold patron, the recall patron or
"None"
7) Set TransfersMaxDaysWarning low and note the "days late" badge appears
8) Click "Cancel transfer" and note the transfer is cancelled
9) A library with no incoming transfers will get "No transfers to receive"
Signed-off-by: Alex Carver [Acerock7] <alex@rcls.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
circulation.pl still replaced the due date of an on-site checkout of a
booked item with the booking end date: with SpecifyDueDate disabled
the end-of-today due date computed for on-site checkouts was
clobbered, and with it enabled the same happened whenever staff left
the due date field empty. An on-site loan could therefore be due back
days after the on-site session.
- never stretch an on-site checkout to the booking end date; the due
date behaves exactly as for a non-booked on-site checkout and
AddIssue shrinks the booking end_date to the actual due date instead
Test plan:
1. Enable OnSiteCheckouts, disable SpecifyDueDate
2. Book an item for a patron starting today
3. Check the item out to them with 'On-site checkout' ticked
4. Without this patch the checkout is due at the booking end date;
with it the checkout is due at the end of today and the booking
end date follows it
5. Repeat with SpecifyDueDate enabled and the due date field left
empty; the due date follows the circulation rules instead of the
booking end date
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
When checking out a booked item, circulation.pl unconditionally
replaced the due date with the booking end date, silently discarding
any due date staff had explicitly specified - even after they had just
confirmed the BOOKED_DUE_DATE_CLASH warning saying they wanted it.
The booking end date remains the default when no due date is
specified; an explicit override (with SpecifyDueDate enabled) is now
passed through to AddIssue, which syncs the booking end_date with it
where possible and keeps the original end date when the override would
clash with a subsequent booking (as warned).
Test plan:
1) Create a booking and check the item out without specifying a due
date; confirm the due date defaults to the booking end date
2) Return the item, book it again, and check out specifying an
explicit due date; confirm the checkout uses that date and the
booking end date follows it
Sponsored-by: OpenFifth <https://openfifth.co.uk/\>
Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/\>
Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
CanBookBeRenewed checked bookings by asking Koha::Item->find_booking
for the first booking that clashes with the renewal period. When the
renewing patron's own booking satisfies this checkout, that booking is
returned first and renewal is allowed - subsequent bookings for the
item were never considered. A patron could therefore renew a booked
item straight through the start of the next patron's booking.
Additionally, when staff renew with an explicit due date (the renewal
due date input on the checkouts screen, or the hard due date on
circ/renew.pl), CanBookBeRenewed validated a *calculated* due date
whilst AddRenewal then applied the *requested* one, so the requested
date was never checked against bookings at all.
This patch:
* repeats the booking lookup with the patron's own booking excluded,
refusing the renewal ('booked') when it would run into the next
booking for the item
* adds an optional $date_due parameter to CanBookBeRenewed, used in
place of the calculated due date for the bookings check, and threads
the requested date through from svc/renew and circ/renew.pl
Test plan:
1) Run t/db_dependent/Circulation.t - the extended
'CanBookBeRenewed | bookings' subtest covers both the calculated
and requested due date cases
2) Check out a booked item to its patron, add a subsequent booking for
another patron, and attempt to renew past the second booking's
start date from the checkouts screen; confirm the renewal is
refused as 'booked'
Sponsored-by: OpenFifth <https://openfifth.co.uk/\>
Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/\>
Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
To test:
1. Have some overdues
2. Go to circ/overdue.pl
3. Notice the the 'Patron' column the name is prefixed with the biblio title
4. This is meant to be the borrowertitle
5. APPLY PATCH, restart_all
6. Now you should see only the borrower/parton name and info.
7. Edit the patron and add a " Salutation"
8. In the overdue report this should now display
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jan Kissig <bibliothek@th-wildau.de>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
When one tries to transfer an item that could fill a pending hold
to a library that is not the holds pickup library, Koha gives only
a option to transfer item to pickup library. This patch adds
new option to ignore hold and transfer item to the library user
selected in transfer tool.
To test:
1. Log into Library A.
2. Find or create a biblio with 1 holdable item at Library A.
3. Place a hold for the biblio with pickup at Library B.
4. Navigate to Circulation > Transfers.
5. Attempt to transfer item to Library C.
=> Note that Koha only allows to transfer item to Library B,
cancel hold and attempt transfer or return to the transfer tool.
6. Apply this patch.
7. Attempt to transfer item again.
=> Note that there is now an option to ignore the hold and transfer
item to Library C.
=> When option to transfer item to the Library C is selected, confirm
that Koha tells that transfer was made to Library C and a new transfer
was made to database.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
When one tries to transfer an item that could fill a pending hold
to a library that is not the holds pickup library, Koha gives only
a option to transfer item to pickup library. When this option
is chosen, Koha tells that item is being transfered to selected
library not to pickup library but fails to create the transfer.
This patch fixes this by setting op variable as "cud-transfer"
and tobranchcd as holds pickup library so that transfer is actually
made and target library is displaued correctly.
To test:
1. Log into Library A.
2. Find or create a biblio with 1 holdable item at Library A.
3. Place a hold for pickup at Library B.
4. Navigate to Circulation > Transfers.
5. Attempt to send your item to Library C.
6. Koha gives you three options. Pick the first one:
"Transfer to Library B."
7. Koha tells you it has transferred the item to Library C.
8. Go to detail.pl for your title, confirm the holdings table
says "there is an item level hold" on your item.
9. Click to the Holds tab for your title, confirm the hold claims
to be in transit.
10. Query the branchtransfers table
SELECT * FROM branchtransfers WHERE itemnumber = [your item]
=> Note that no new transfer was made.
11. Query reserves SELECT * FROM reserves WHERE biblionumber = [your biblio]
=> Confirm your hold has found=T, itemnumber=[your item], and item_level_hold=0
12. Revert trasfer from biblios holds page.
13. Apply this patch.
14. Attempt the transfer again.
=> Koha should now tell that transfer was made to Libary B.
15. Check branchtransfers table again.
=> New transfer should have been made to Library B.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
The early-exit added for the CurbsidePickup syspref check left
policy/curbside_pickups unset, but intranet-bottom.inc's jsinclude
still referenced them unconditionally, causing a client-side
TypeError on every render of the disabled state. Guard the whole
jsinclude block with disabled_for_branch.
Also distinguish the two reasons the page can be disabled: the
CurbsidePickup syspref being off globally vs. this branch simply
not having an enabled curbside pickup policy configured. The
message and link now point staff to the correct admin page for
each case, instead of always suggesting the syspref (which may
already be on).
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This patch solves the following issues:
* Template flow issue: the template called STOP which prevented the
WRAPPER to complete and affected how things were rendered.
* Redirect to 404 if feature disabled. This is common practice in other
modules. The fact things can be executed even with the feature
disabled is not ok (syspref).
* Shortcircuit earlier. Similar to the above, if the feature is
disabled for the current branch, no DB queries and stuff should take
place. Notice the lack of checks actually makes the controller perform
the actions. It is just that it is not displayed afterwards!
To test:
1. Enable the `CurbsidePickup` syspref.
2. 'Activate' the `CircSidebar` syspref.
3. Be on a branch that doesn't have them enabled
4. Go to Circulation > Check in
=> SUCCESS: A nice left-hand sidebar is displayed with access to
Circulation actions
5. Click on 'Curbside pickups'
=> FAIL: The sidebar doesn't display. boo!
6. Apply this patch
7. Restart plack
$ ktd --shell
$ koha-plack --restart kohadev
8. Repeat 4
=> SUCCESS: It renders much better!
9. Sign off :-D
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
The warnings:
[WARN] Use of uninitialized value $patron_session_confirmation in split
at /kohadevbox/koha/circ/circulation.pl line 493.
[WARN] Use of uninitialized value $patron_for_session in numeric eq (==)
at /kohadevbox/koha/circ/circulation.pl line 494.
[WARN] Use of uninitialized value $session_confirmations in split
at /kohadevbox/koha/circ/circulation.pl line 495.
appears in the plack-intranet-error.log.
Test plan:
==========
1. Use a fresh KTD, observe plack-intranet-error.log.
2. Have a barcode of existing item.
3. Find any patron and go to "Check out" tab.
4. Check out item.
==> Warnings should appear in plack-intranet-error.log
5. Apply the patch; restart_all.
6. Repeat 2-4 with another barcode.
==> No warnings in plack-intranet-error.log.
Sponsored-by: Ignatianum University in Cracow
Signed-off-by: David Nind <david@davidnind.com>
Bug 41940: (follow-up) Syntax corrections
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Remove unused patron attribute values sent to the template
Send preferred name
Use SQL to do date comparison to see if an item is overdue
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
We use SQL here to get all the needed info - the query says it is slow, but isn't so bad.
Worse is fetching the patron for each borrower with overdues (and more than once if they have several)
It appears we started grabbing the patron so we could use patron title, but we can just pass the info already fetched.
I additionally fetch the patron category types and update patron-title to allow for hide_patron_infos_if_needed to work
without a patron object - we can just use the branchcode as ultimately that's all we need
To test:
1 - Add many items to your catalog (can use my handy repo randitems.pl)
https://github.com/kidclamp/handy-koha-script
2 - Add many issues (can use randissues.pl from above)
3 - I tested with about 1000
4 - Browse to Circulation->Overdues
5 - Note load time
6 - Apply patch
7 - Restart all
8 - Note load time is faster
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
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>
This patch applies the new style preferences to the preview display and
email sending code.
Sponsored-by: Open Fifth <https://openfifth.co.uk>
Signed-off-by: Marion Durand <marion.durand@biblibre.com>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
1) Enable DisplayAddHoldGroups
2) Go to 'Henry' and click the 'Search to hold' button:
<staff_url>/cgi-bin/koha/members/moremember.pl?borrowernumber=19
3) Search for keyword 'test'. Click the 'Search' button.
4) On the search results page, click the 'Select all' option at the top
5) Click the downward arrow in the 'Place hold' toolbar button.
6) Pick 'Place hold for Henry Acevedo'
7) Tick the 'Treat as hold group' checkbox.
8) Set a pickup location for each of the holds.
9) Click 'Place holds'.
10) Check-in one eligible item (from one of the 3 records we just placed holds on) e.g.: 39999000001310
11) Notice the 'Hold found' modal now shows 'Part of a hold group' with a link directly to the patron's holds.
Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When using strict_sql_modes, the Hold ratios page causes an Incorrect
GROUP BY error and returns an Error 500.
This patch removes uncessary columns from the database query and adds
the biblio columns to the GROUP BY statement, so they can be selected.
Since it's already grouped by biblionumber, it should not cause any
additional rows to be created.
Test plan:
1. Make sure that strict_sql_modes is enabled in the koha-conf.xml
file.
2. Place at least one hold on a book.
3. Go to Circulation and select Hold ratios.
4. Observe that you get an Error 500.
5. Apply patch.
6. Repeat step 3.
7. Observe that you can view the page.
8. If the table is empty, change the ratio to 1.
9. Sign off.
Sponsored-by: Lund University Library
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test
The following should work with either email or SMS notices sent from the Add Message button in a patron record
1 - create a notice in module Patrons (custom message) for all libraries
2 - create a notice in module Patrons (custom message) for Centerville
3 - while logged in at Centerville, confirm you can see and enqueue your all libraries message
4 - while logged in at Centerville, confirm you can see but cannot successfully enqueue your Centerville message
5 - while logged in at Fairfield, confirm you can see but cannot successfully enqueue your Centerville message
6 - apply patch, restart_all
7 - while logged in at Fairfield, confirm you can see and enqueue your all libraries message
8 - while logged in at Fairfield, confirm you cannot see your Centerville message
9 - while logged in at Centervielle, confirm you can see and enqueue your Centerville message
Signed-off-by: Juliet Heltibridle <jheltibridle@rcplib.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
To test:
1 - have an staff account with 'send_messages_to_borrowers' permission but not top level 'borrowers' permission
2 - have a value in SMSSendDriver system preference
3 - log in under your staff account and confirm you can send both email and SMS messages from the Add Message button on a patron record
4 - apply patch, updatedatabase, restart_all
5 - confirm your staff account now has 'send_messages_to_borrowers_email' permission rather than 'send_messages_to_borrowers'
6 - confirm your staff account can now only send email messages from the Add Message button on a patron record
7 - add 'send_messages_to_borrowers_sms' permission to your staff account
8 - confirm your staff account can now send both email and sms messages from the Add Message button on a patron record
9 - remove 'send_messages_to_borrowers_email' from your staff account
10 - confirm your staff account can now only send sms messages from the Add Message button on a patron record
Signed-off-by: Juliet Heltibridle <jheltibridle@rcplib.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
This patch implements fine override functionality for the checkouts
table on the circulation page (circ/circulation.pl), completing the
debt override feature for all renewal workflows.
Changes:
- Added override_debt checkbox to checkouts-table.inc when
AllowFineOverrideRenewing preference is enabled
- Updated /svc/renew to accept and process override_debt parameter,
matching the pattern used for override_limit
- Enhanced circulation-api-client.js to pass override_debt parameter
through the renewal API call
- Implemented specific CSS classes for renewal error types
(renewals-allowed-too_many, renewals-allowed-too_much_owing, etc.)
to enable selective checkbox control
- Modified override checkbox handlers to selectively enable only
relevant renewal checkboxes based on the specific blocking error:
* override_limit enables checkboxes for 'too_many' and 'on_reserve'
* override_debt enables checkboxes for 'too_much_owing' and
'auto_too_much_owing'
- Added AllowFineOverrideRenewing JavaScript variable to circulation.tt
This provides clear visual feedback to staff about which renewals will
be affected by each override option, improving usability and reducing
confusion when multiple items have different blocking reasons.
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Standardizes error code spelling across the codebase:
- Changes 'too_much_oweing' to 'too_much_owing'
- Changes 'auto_too_much_oweing' to 'auto_too_much_owing'
The word "owing" is the correct spelling in English.
Files updated:
- C4/Circulation.pm
- C4/SIP/Sip/MsgType.pm
- circ/renew.pl
- koha-tmpl/intranet-tmpl/prog/en/modules/circ/renew.tt
- koha-tmpl/intranet-tmpl/prog/js/checkouts.js
- koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-reserve.tt
- koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-user.tt
- misc/cronjobs/automatic_renewals.pl
- opac/opac-reserve.pl
- opac/opac-user.pl
- t/db_dependent/Circulation.t
All tests should pass successfully.
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
This commit addresses several issues found in QA review:
1. Fixed logic bug in C4::Circulation::CanBookBeRenewed
- Removed incorrect check of AllowFineOverrideRenewing preference
- The function now always returns 'too_much_oweing' error when
patron balance exceeds FineNoRenewals limit
- AllowFineOverrideRenewing should only control UI override
capability, not the core renewal check
2. Added permission check in circ/renew.pl
- Override is now only allowed when both override_debt parameter
is set AND AllowFineOverrideRenewing preference is enabled
- Prevents security issue where staff could bypass the preference
by crafting POST requests
3. Fixed template to conditionally display override button
- Override button in renew.tt now only shows when
AllowFineOverrideRenewing is enabled
- Prevents confusion when override is not permitted
4. Added test coverage
- Tests verify CanBookBeRenewed behavior with AllowFineOverrideRenewing
both enabled and disabled
- Confirms error is always returned regardless of preference setting
5. Fixed minor issues
- Fixed typo: "he patron" -> "the patron" in checkouts.js
- Fixed typo: OPACFineNoRenewalsIncludeCredit ->
OPACFineNoRenewalsIncludeCredits in test
All tests should pass successfully.
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
This moves the basic calculation for too_much_oweing out of the
controller and into the class method.
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
OPACFineNoRenewals no longer applies just to OPAC.
To avoid confusion rename it as FineNoRenewals and
also rename all occurences in code.
To test, confirm everything works as described in
previous test plans.
Also prove t/db_dependent/Circulation.t
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
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>
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>
The warning
[WARN] Use of uninitialized value in string eq at
/kohadevbox/koha/circ/del_message.pl line 54.
appears in plack-intranet-error.log
Test plan:
==========
1. Observe plack-intranet-error.log
2. Search for any patron and go to "Check out" tab.
3. Add message for patron. Added message is shown in "Message" area
with "Edit" and "Delete" links.
4. Click "Delete" and confirm modal.
5. Warning appears in plack-intranet-error.log
6. Apply the patch; restart_all
7. Repeat 3-4. No warning appears.
Sponsored-by: Ignatianum University in Cracow
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The LibraryFloatLimitTransferRequest message was never set in C4::Circulation,
making this code unreachable. Float limit transfers are already properly handled
through the existing transfer message system (WasTransfered/NeedsTransfer) with
TransferTrigger set to 'LibraryFloatLimit'.
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds the collection code to the transfers to receive report
It wraps it in a span for styling/hiding
To test:
1 - Transfer some books with collection code set to another branch
2 - Sign in as that branch
3 - Circulation -> Transfers to receive
4 - No collection code shown
5 - Apply patch
6 - Refresh
7 - See collection code
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1. Make sure SMSSendDriver system preference is enabled
2. In staff client, navigate to patron details of any patron
3. From the members menu toolbar, click "Add Message"
4. Under "Add a message for", select "SMS - sms number of patron"
5. Write a custom message
6. Click "Save"
7. Navigate to patron's Notices tab
8. Observe a new notice titled "SMS added by a librarian"
9. Click it
10. Observe the content you wrote in step 5
11. Repeat steps 2-4
12. Select predefined patron notice. If you don't have one,
navigate to Tools > Notices and slips > New notice > Patrons (custom message)
and add content under sms delivery option
13. Repeat steps 6-7
14. Observe your custom message in the notices table
15. Observe your custom message content when you click the notice
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Charlie Arthur <carthur@slolibrary.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When changing library in circ/set-library.pl, desk and register values
were not being properly cleared from the session. This caused stale
desk/register data from the previous library to persist, resulting in:
- Incorrect cashup displays showing wrong library's register
- POS defaulting to registers from different libraries
- Session state inconsistent with visual UI
Three issues fixed:
1. Template: Changed register "None" option ID from "set-library-noregister"
to "noregister" to match JavaScript expectations (consistent with desk handling)
2. Desk logic: Changed condition to use defined() and explicitly clear session
when "No desk" is selected
3. Register logic: Added session clearing when "No register" is selected and
fixed condition to handle empty initial state
Test plan:
1. Select Library A with Register 5
2. Change to Library B without selecting a register
3. Verify register is cleared from session (check POS page)
4. Repeat for desk selection
5. Verify explicit "-- None --" selection clears session values
Signed-off-by: Jason Robb <jrobb@sekls.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When a hold that belongs to a hold group becomes 'In transit' or 'Waiting',
it now becomes that hold group's target hold.
Subsequent check-ins that would satisfy other holds in the same hold
group are skipped, as they are part of a group that already has a
target.
The behavior change introduced here that differs from the groundwork
from bug 15516 are:
1) Before, only 'Waiting' holds would consider an action based on hold
groups i.e. cancel the other holds in the group. Now 'In transit'
also does this.
2) This hold groups related action used to be to cancel other holds in
the group. This is no longer the case. Now, the respective hold is
set as the hold group's target. This causes the holds in the same group that
are not the target to be skipped when a check-in that would otherwise
satisfy one of those holds happens. This behavior change allows the following
scenario which wasn't possible before:
A hold is marked 'Waiting'. It becomes its group target. For any reason,
that hold is then cancelled. Any subsequent check-in of an item of a
hold in this group may now becomes that group's new target.
Similarly, the same use case above is also true for 'In transit' holds.
----
The 'skip non-target holds' behavior has been added to check-in logic
(Reserves::_Findgroupreserve), 'holds to pull' logic
(pendingreserves.pl) and holds queue (HoldsQueue.pm).
Signed-off-by: Anneli Österman <anneli.osterman@koha-suomi.fi>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: David Flater <flaterdavid@gmail.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
0. APPLY PATCH and restart_all
1. Place some holds with different shelving locations and collection
codes.
2. Build the holds queue
3. Go to Circulation > Holds queue
4. Notice that shelfing location and collection code are now multi
select2 dropdowns
5. Try searching for various combos of shelfing locations and collection
codes.
6. Make sure the results are correct.
7. After making selections and running the search make sure your
selections are retained in the search form in the left nav bar
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch removes the duplicate logging code from circ/returns.pl that
was part of the original Bug 9762 implementation.
The original implementation added a separate logaction() call when
ignoring holds on return. This code created a custom JSON log entry
with the message "return an element that is reserved".
However, this logging appears to have been orphaned - there is no
corresponding Alternative implementation for return override logging
in the current codebase. The code was creating log entries but they
were not properly integrated with any override confirmation workflow.
Changes:
circ/returns.pl:
- Removed entire else block that created custom override log entries
- Removed unused variables: $message, @message, $user, $branchcode, $barcode
- Removed C4::Log qw(logaction) import as it's no longer needed
This eliminates the orphaned logging code and ensures returns.pl only
uses standard Koha logging mechanisms.
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>
This patch removes the duplicate logging code from renewal scripts
(circ/renew.pl and svc/renew) that was part of the original Bug 9762
implementation.
The original implementation created separate logaction() calls with
custom JSON messages whenever renewal overrides occurred. This caused
double logging alongside the Alternative implementation which properly
logs overrides via the confirmations parameter in AddRenewal.
Changes:
circ/renew.pl:
- Removed unused variables: $user, $branchcode, @message
- Removed separate logaction() calls for override logging
- Changed to use confirmations array with proper codes:
* 'RENEWAL_LIMIT' for override_limit
* 'ON_RESERVE' for override_holds
- Removed C4::Log qw(logaction) import
svc/renew:
- Removed unused variables: $borrower, $user, $message, @message
- Removed separate logaction() calls for override logging
- Changed to use confirmations array with proper codes:
* 'ON_RESERVE' for on_reserve override
* 'RENEWAL_LIMIT' for too_many override
- Removed C4::Log qw(logaction) import
The Alternative implementation in AddRenewal will now handle all
override logging consistently through the confirmations parameter.
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>
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>
This patch does two things:
1:
It prevents rebulding the real time holds queue during a checkin if a reserve was found.
The reserve will either:
a - be set to waiting if at correct location and no confirmation - this is fine because we will rebuild the queue when
filling the hold
b - trigger a popup whihc will rebuild the queue when confirming the transfer, or be ignored
2:
It adds a form to ignoring a hold so that we can rebuild the holds queue if we decided not to use the current item
to fill the found hold
To test:
0 - Enable RealTimeHoldsQueue
1 - Place several holds for different libraries on a title
2 - Checkout a copy to a patron at current library (ignore current holds)
3 - Clean up DB so we can see outcomes from next steps:
delete from branchtransfers; delete from background_jobs; update reserves SET found=NULL where found='T';
4 - Check in item, confirm hold
5 - Check background jobs, note two rebuilds of the holds queue
6 - Check item out to previous patron, repeat 3
7 - Check in item, ignore the hold
8 - Check background jobs, note only one rebuild
9 - Apply patch, restart all
10 - Checkout item, repeat 3
11 - Checkin item, confirm hold
12 - Check background jobs, onlt one rebuild of holds queue
13 - Checkout item, repeat 3
14 - Checkin item, ignore hold
15 - Check background jobs, only one rebuild of holds queue
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>
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>
Martin Renvoize
Aleisha Amohia
Jacob O'Mara
Kyle M Hall
Paul Derscheid
Lucas Gass
Andrew Fuerste Henry
Emmi Takkinen
Tomas Cohen Arazi
Roman Dolny
Pedro Amorim
Nick Clemens
Martin Renvoize
Kevin Carnes
Lari Taskula
Hammat Wele
Laura_Escamilla