Bug 39802 - Add CircControl equivalent system preference for lost item fees and actions
Summary: Add CircControl equivalent system preference for lost item fees and actions
Status: Needs Signoff
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Nick Clemens (kidclamp)
QA Contact: Testopia
URL:
Keywords:
Depends on: 9596
Blocks: 35612 36506
  Show dependency treegraph
 
Reported: 2025-05-01 16:01 UTC by Andrew Fuerste-Henry
Modified: 2025-09-19 13:25 UTC (History)
4 users (show)

See Also:
GIT URL:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 39802: Add LostChargesControl system preference (3.64 KB, patch)
2025-08-06 15:22 UTC, Nick Clemens (kidclamp)
Details | Diff | Splinter Review
Bug 39802: Use new preference in longoverdue cron (1.69 KB, patch)
2025-08-06 15:22 UTC, Nick Clemens (kidclamp)
Details | Diff | Splinter Review
Bug 39802: Report when no branches will be selected and exit (1.97 KB, patch)
2025-08-06 15:22 UTC, Nick Clemens (kidclamp)
Details | Diff | Splinter Review
Bug 39802: Atomic update file (1.58 KB, patch)
2025-08-06 18:02 UTC, Nick Clemens (kidclamp)
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Fuerste-Henry 2025-05-01 16:01:26 UTC
We need something like CircControlLostBranch with which to specify which branch should be followed for actions and fees related to lost items.

Since Bug 9596 the longoverdue cron can be limited by branch, but it follows CircControl when doing so. Lost item fee and processing fee refunds also follow CircControl.

However, some libraries want checkout limits and periods to be governed by issuing branch but lost item behavior to be based on the owning library of the item.
Comment 1 Andrew Fuerste-Henry 2025-05-01 16:29:03 UTC
I forgot about our friend RefundLostOnReturnControl, so I was a bit wrong in my first comment.

The longoverdue cron follows CircControl currently.
Lost item fee refunds follow RefundLostOnReturnControl.
Comment 2 Nick Clemens (kidclamp) 2025-08-06 15:22:25 UTC
Created attachment 185160 [details] [review]
Bug 39802: Add LostChargesControl system preference
Comment 3 Nick Clemens (kidclamp) 2025-08-06 15:22:28 UTC
Created attachment 185161 [details] [review]
Bug 39802: Use new preference in longoverdue cron

The test plan here is largely confirming that nothing has changed.

Using CircControl here has an existing problem - when set to 'PickupLibrary'
the check in this cron looks for items from the userenv branch - the cron doesn't
have a userenv branch, it is undef, so for any library limiting by branch and
with CircControl set to 'PickupLibrary' / 'the library you are logged in at' the cron will do nothing
Comment 4 Nick Clemens (kidclamp) 2025-08-06 15:22:30 UTC
Created attachment 185162 [details] [review]
Bug 39802: Report when no branches will be selected and exit

This highlights the issue mentioned in the last patch, reporting that
nothign will be done and exiting the script

To test:
1 - perl misc/cronjobs/longoverdue.pl  -l 5=1 --library CPL
2 - Confirm script exits with warning that nothing has been done
Comment 5 Nick Clemens (kidclamp) 2025-08-06 18:02:19 UTC
Created attachment 185165 [details] [review]
Bug 39802: Atomic update file
Comment 6 Andrew Fuerste-Henry 2025-09-17 19:39:22 UTC
In testing just now, the cron did not appear to respect this system preference. To recreate:
 
- have bib with 6 items, 2 each with homebranch Centerville, Fairfield, Midway
- have patron with branch=Midway
- with Koha set to Centerville, check out 1 item from each homebranch to your patron
- set Koha to Midway and check remaining items out to patron

- set LostChargesControl to "library the item is from"
- wonder aloud whether or not HomeOrHoldingBranch applies, find no answer, move forward anyway
- perl misc/cronjobs/longoverdue.pl -l 7=2 -c  --library CPL
- cron feedback says it will mark all 6 checkouts lost, even though only two of these items have CPL as their homebranch (and only 3 have it as the holdingbranch)

- set LostChargesControl to "library the item is from"
- perl misc/cronjobs/longoverdue.pl -l 7=2 -c  --library CPL
- cron feedback says it will mark all 6 checkouts lost, even though 0 of them are checkouts to a patron from CPL
Comment 7 Nick Clemens (kidclamp) 2025-09-19 11:28:40 UTC
(In reply to Andrew Fuerste-Henry from comment #6)
> In testing just now, the cron did not appear to respect this system

> - perl misc/cronjobs/longoverdue.pl -l 7=2 -c  --library CPL

The -c flag takes a value, so the library param here is not being read correctly, it should work like:

perl misc/cronjobs/longoverdue.pl -l 7=2 -c 2 --library CPL
Comment 8 Andrew Fuerste-Henry 2025-09-19 13:09:55 UTC
Updated test plan:
1 - have bib with 6 items, 2 each with homebranch Centerville (CPL), Fairfield (FFL), Midway (MPL)
2 - have patron with branch=Midway
3 - with Koha set to Centerville, set a due date more than 7 days ago and check out 1 item from each homebranch to your patron
4 - set Koha to Midway, make sure you still have a due date more than 7 days in the past, and check remaining items out to patron

At this point your 6 checkouts should have this mix of values:
- holdingbranch: 3 CPL and 3 MPL
- homebranch: 2 CPL, 2 FFL, 2 MPL

5 - set LostChargesControl to "library the item is from"
6 - set HomeOrHoldingBranch to holdingbranch
7 - run the longoverdue cron for CPL without the --confirm flag (perl misc/cronjobs/longoverdue.pl -l 7=2 -c 2 --library CPL)
8 - confirm in cron output that only the 3 with holdingbranch=CPL would be acted upon
9 - run the longoverdue cron for FFL without the --confirm flag (perl misc/cronjobs/longoverdue.pl -l 7=2 -c 2 --library FFL)
10 - confirm no items would be acted upon
11 - run the longoverdue cron for MPL without the --confirm flag (perl misc/cronjobs/longoverdue.pl -l 7=2 -c 2 --library MPL)
12 - confirm only the 3 items with holdingbranch=MPL would be acted upon

13 - set HomeOrHoldingBranch to homebranch
14 - run the longoverdue cron for CPL without the --confirm flag (perl misc/cronjobs/longoverdue.pl -l 7=2 -c 2 --library CPL)
15 - confirm that only the 2 with homebranch=CPL would be acted upon
16 - run the longoverdue cron for FFL without the --confirm flag (perl misc/cronjobs/longoverdue.pl -l 7=2 -c 2 --library FFL)
17 - confirm that only the 2 with homebranch=FFL would be acted upon
18 - run the longoverdue cron for MPL without the --confirm flag (perl misc/cronjobs/longoverdue.pl -l 7=2 -c 2 --library MPL)
19 - confirm that only the 2 with homebranch=MPL would be acted upon

20 - set LostChargesControl to "library the patron is from"
21 - run the longoverdue cron for CPL without the --confirm flag (perl misc/cronjobs/longoverdue.pl -l 7=2 -c 2 --library CPL)
22 - confirm no items would be acted upon
23 - run the longoverdue cron for FFL without the --confirm flag (perl misc/cronjobs/longoverdue.pl -l 7=2 -c 2 --library FFL)
24 - confirm no items would be acted upon
25 - run the longoverdue cron for MPL without the --confirm flag (perl misc/cronjobs/longoverdue.pl -l 7=2 -c 2 --library MPL)
26 - confirm all 6 items would be acted upon
27 - edit your patron, chnge their branch to CPL
28 - run the longoverdue cron for CPL without the --confirm flag (perl misc/cronjobs/longoverdue.pl -l 7=2 -c 2 --library CPL)
29 - confirm all 6 items would be acted upon

30 - set LostChargesControl to "library you are logged in at"
31 - run the longoverdue cron for CPL without the --confirm flag (perl misc/cronjobs/longoverdue.pl -l 7=2 -c 2 --library CPL)
32 - confirm cron tells you this doesn't work: "There is no branch set for the cron user, LostCharge Control is set to 'library you are logged in at'.
No branches will satisfy this requirement - exiting."