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: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 7a392f111e)
Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com>
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>
(cherry picked from commit 171f727734)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
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>
(cherry picked from commit 6a12116dd2)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
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>
(cherry picked from commit e3862dc81b)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
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>
(cherry picked from commit d463fce02d)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
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>
(cherry picked from commit 55a934fc0d)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
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>
(cherry picked from commit ea4600476e)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
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>
(cherry picked from commit 28b479d114)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
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>
(cherry picked from commit 3a1bd59197)
Signed-off-by: Jacob O'Mara <jacob.omara@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>
(cherry picked from commit 3dd4691076)
Signed-off-by: Jacob O'Mara <jacob.omara@openfifth.co.uk>
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>
(cherry picked from commit 643da6f9cd)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
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>
(cherry picked from commit bee9d8da78)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
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>
When implemented, the message here was believed to either be about Duplicate IDs, or guarantor issues.
We are now seeing a wider variety of issues possible from SQL errors, lock timeout or missings rows as examples
This patch adds an 'ErrorMessage' message to the return from AddReturn and displays it to the user.
To test:
1 - Issue an item to a patron, note the itemnumber
2 - On the command line, lock the row:
sudo koha-mysql kohadev
START TRANSACTION;
SELECT * FROM issues WHERE itemnumber=975 FOR UPDATE;
leave mysql open at this point
3 - On the interface, check in the item, wait a bit
4 - After a bit you get the error to check the config page, but nothing is there
5 - close mysql, apply patch, restart all
6 - Repeat 2
7 - Check in the item, wait a bit
8 - Note you now get the error from the DB:
Error: (DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Lock wait timeout exceeded; try restarting transaction at /kohadevbox/koha/Koha/Object.pm line 174 )
9 - Sign off!
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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>
We never actually pass `$message` back to anywhere so there's no reason
to create it in the first place.
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>
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>
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>
Signed-off-by: David Flater <flaterdavid@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
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>
This patch adds a catch during circulatoin actions and passes a message back to the caller
For checkouts and renewals we don't have a method for passing messages so we simply catch the exception
and warn - this seems reasonable, as we have now added a warning on the patron display that they are missing
a guarantor
To test:
1 - Create a Child type patron with no guarantor
2 - Create a patron in a non-child category that can_be_guarantee with no guarantor
3 - Check out an item to each patron above
4 - Enable system preference 'ChildNeedsGuarantor' and TrackLastPatronActivityTriggers - select all
5 - In mysql
UPDATE borrowers SET datelastseen = '2025-01-01';
6 - Restart all to clear cache (so update last seen will update)
7 - Attempt to checkout a book to either patron - 500 error
8 - Attempt to returnt he books the patrons have checked out - 500 error
9 - Attempt to renew their items - 500 error
10 - Apply patches, restart all
11 - Repeat checkout, renewal, checkin
12 - On checkout and renewal there should be a warning on the patron page, but actions succeed with no additional problems
13 - On return you get a warning letting you know the action succeeded but there is still a problem to resolve
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
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>
In order to remove false positives with the QA script we should replace some tabs with spaces.
There are more but I wanted to make sure no regression would be
introduced
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. Place multiple holds, good to have at least 4, for pickup at a location, I used Nick's handy script
2. Perl misc/cronjobs/holds/build_holds_queue.pl
3. Check in at least 4 items for pickup at one location so they'll be wating
4. Update the expiration date on those holds using ktd --dbshell
update reserves set expirationdate = DATE('2024-01-01') where branchcode='CPL';
5. On Circulation > Holds waiting past their expiration date tab use the cancel button that is in the actions column to cancel a hold
The page loads on the Holds waiting tab, although in the url you see /circ/waitingreserves.pl?tab=holdsover
6. APPLY PATCH
7. Try 1 - 5 again, this time after step 5 you should be redirected.
8. Try cancelling holds with a transfer, ensuring you get redirected correctly.
Signed-off-by: Andrew Auld <andrew.auld@openfifth.co.uk>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
because of automatic changes in circ/transferstoreceive.tt
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch ignores limits when updating a wrong transfer to ensure we can return a book
home when checked in at the wrong branch
To test:
1 - Enable UseBranchTransferLimits based on 'Collection code'
2 - Disable transfers for FIC from:
CPL -> FFL
CPL -> IPT
FFL -> CPL
FFL -> IPT
IPT -> CPL
IPT -> FFL
3 - Set library to IPT
4 - Checkin an FFL item
5 - It generates a transfer home
6 - Set library to CPL
7 - Check the item in
8 - 500 error, and in logs:
==> /var/log/koha/kohadev/plack-error.log <==
Exception 'Koha::Exceptions::Item::Transfer::Limit' thrown 'Transfer not allowed'
9 - Apply patch, restart all
10 - Check item in again
11 - Success! Transfer updated
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds information about whether an entry in the overdue report
is overdue so we can style dates accordingly. We can't assume that each
result is overdue because the report can be changed to include all
checked out items.
To test, apply the patch and go to Circulation.
- Check out to a patron.
- Use the "Specify due date" option to check out some items with due
dates in the past, due dates today, and due dates in the future.
- Go to Circulation -> Overdues.
- You should see the items which have due dates in the past. The date in
the "Due date" column should be red text. The "Checked out on" date
should be regular text.
- In the sidebar, check the "Show any items currently checked out"
checkbox and submit the form.
- You should now see all the items you just checked out. Only the
overdue items should show their due date in red.
Sponsored-by: Athens County Public Libraries
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Lucas Gass
Roman Dolny
Nick Clemens
Martin Renvoize
Pedro Amorim
Kevin Carnes
Andrew Fuerste Henry
Lari Taskula
Hammat Wele
Laura_Escamilla
Tomas Cohen Arazi
Matthias Le Gac
emilyrose
David Cook
Aleisha Amohia
Baptiste Wojtkowski
Emily Lamancusa
Jonathan Druart
Owen Leonard