Always include the plural version, not the singular one (the plural
imports the singular)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This patch replaces all calls to C4::Stats::UpdateStats with the wrapped
function from the Koha namespace. As this is the last function in C4::Stats, the
module is also deleted.
Several tests depended on transitive includes to Koha::Statistics through
C4::Stats. I've identified uses of that module by searching, and added the
necessary use in each case. I've run `prove -r t xt` with this patch applied and
didn't hit any relevant errors.
Test plan:
1. Inspect the patch, and verify each changed call maintains the same parameters.
2. Apply patch.
3. Prove the following files:
- t/db_dependent/Accounts.t
- t/db_dependent/Circulation.t
- t/db_dependent/Koha/Account.t
- t/db_dependent/Koha/ILL/Request.t
- t/db_dependent/Koha/Item.t
- t/db_dependent/Koha/Pseudonymization.t
- t/db_dependent/Koha/Recalls.t
Sponsored-by: Open Fifth
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
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>
This bug will rename the UseEmailReceipts to AutomaticEmailReceipts, to
make it clearer the purpose of this syspref. This is because the receipts
dropdown is no longer conditional, and will always show, even if
AutomaticEmailReceipts is switched off.
To test (steps a-e before applying patch):
a) search sysprefs for 'EmailReceipts'
1) note the name is currently 'UseEmailReceipts'
2) enable this syspref
b) go to members/maninvoice.pl?borrowernumber=51
1) enter an amount (e.g. 100)
2) save & pay, confirm
c) go to members/boraccount.pl?borrowernumber=51
1) note that the receipt dropdown is visible
d) go to members/notices.pl?borrowernumber=51
1) note that a receipt was automatically sent
e) apply the patch, upgrade the db schema
f) search sysprefs for 'EmailReceipts'
1) note the name is now 'AutomaticEmailReceipts'
g) go to members/maninvoice.pl?borrowernumber=51
1) enter an amount (e.g. 100)
2) save & pay, confirm
h) go to members/boraccount.pl?borrowernumber=51
1) note that the receipt dropdown is no longer visible
i) go to members/notices.pl?borrowernumber=51
1) note that a receipt was automatically sent again
j) disable the 'AutomaticEmailReceipts' syspref
k) go to members/memberentry.pl?op=edit_form&destination=circ&borrowernumber=19
1) add a valid email address
k) go to members/maninvoice.pl?borrowernumber=51
1) enter an amount (e.g. 100)
2) save & pay, confirm
l) go to members/boraccount.pl?borrowernumber=51
1) note that the receipt dropdown is now visible
m) go to members/notices.pl?borrowernumber=51
1) note that a receipt was NOT automatically sent
n) go to members/boraccount.pl?borrowernumber=51
1) on any account line where a payment is made, click receipts > email
o) go to members/notices.pl?borrowernumber=51
1) confirm a manual notice has been generated
p) make coffee & have a mini disco
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Added head2 right before sub with missing POD
Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This commit is generated using:
% perl misc/devel/tidy.pl
*within* ktd, to get the same version of perltidy than what will be used
by our CI (currently v20230309).
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Additional handling for the case where a credit is added with an
issue_id after the issue is returned.
add_credit will keep the same method signature, where the issue_id
parameter may now refer to a current issue or an old issue. It will then
internally determine whether it is a current or old checkout and handle
it appropriately.
If the caller is updating an account line, or adding a credit to refund
an existing debit, they may not need to know whether it is for a current
checkout or an old checkout. In this case, they can use the account
line's ->checkout accessor to pass in the appropriate issue_id
regardless of whether it is a current or old checkout.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We need additional handling for the case where a debt may be added with
an issue_id after the issue is returned.
This patch tries to fix that at a low level, but introduces new test
failures in t/db_dependent/Circulation.t to be investigated.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Actually, the module is not even needed anymore here.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch moves the del_restrictions_after_payment from before the
actual credit application call inside Koha::Account::pay to after the
application of credits to debits in Koha::Account::Line::apply.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Some libraries debar Patrons at the end of the year for having unpaid fines,
like in Bug 15157. Currently librarians have to manually remove this type of
debarments after Patron has paid his/her fines.
This patch adds ability to create restrictions which are lifted after
patron pays ceratain amount of fines.
To test:
1. Apply this patch.
2. Restart your services if needed.
3. Navigate to page restrictions.pl.
=> Note that table has two new colums in it, "Lift after payment?" and "Fee limit".
4. Add new restriction which has "Lift after payment?" set
as Yes and fee limit as 5.
5. Create fees for a patron so they exceed fee limit e.g. 10
6. Add restriction made in step 2. for the patron
7. Pay patrons fees partially so that they go under fee limit
=> Note that patrons restriction should now be lifted.
Also prove t/db_dependent/Patron/Borrower_Debarments.t.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Anneli Österman <anneli.osterman@koha-suomi.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1. Turn on RequirePaymentType
2. Create a manual invoice and then attempt to write it off.
3. 500 error
4. Turn of RequirePaymentType, no error.
5. Apply patch, restart_all
6. Try step 2 again, you should not get an error
7. prove t/db_dependent/Koha/Account.t
8. Make sure tests pass
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Found while running Items.t on top of 33608.
Another exception was thrown but not rethrown.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
1. Turn on RequirePaymentType
2. Create a manual invocie on a patron account
3. Go to pay it, 'Payment type:' is marked as required.
4. In the inscept the select input ( #payment_type ) with your browser's dev tools. Removed the required attribute.
5. You are able to make the payment without a payment type.
6. Apply patch and restart_all
7. Try 4-5 again. This time you should get a 500 error and the payment should not go through.
8. Try a paymnet again this time manipulate the DOM and change the value of 'CASH' to something else like 'SOMETHINGELSE'.
9. Try to submit the payment and again you will get a 500 error. The payment should not go through.
10. Turn RequirePaymentType off. Try a payment with a payment type, you shoud be successful.
11. Make sure tests will pass
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
1. Turn on RequirePaymentType
2. Create a manual invocie on a patron account
3. Go to pay it, 'Payment type:' is marked as required.
4. In the inscept the select input ( #payment_type ) with your browser's dev tools. Removed the required attribute.
5. You are able to make the payment without a payment type.
6. Apply patch and restart_all
7. Try 4-5 again. This time you should get a 500 error and the payment should not go through.
8. Turn RequirePaymentType off. Try a payment with a payment type, you shoud be successful.
9. Make sure tests will pass:
prove -v t/db_dependent/Koha/Account.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1. Make sure MarkLostItemsAsReturned is set so a lost item will stay on a patrons account after being marked as lost.
2. Check an item out to a patron, make sure it has a replacementprice
3. Mark the item as lost.
4. Now check the item in.
5. Go to the patrons account -> transaction tab. You should see 2 accountlines related to the item.
6. For the account type 'Lost item' you will see issue infomation ( check out date, due date, checkouted out from, etc )
7. For the account type 'Lost item fee refund' there is no issue information.
8. Apply patch
9. Try 2 - 6 again. This time the 'Lost item fee refund' should include issue information.
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Currently the debit types to be excluded from the noissuescharge syspref are
hardcoded in non_issues_charges which gives no flexibility for selecting which
debit types should be included. This patch amends the subroutine to use a
database flag to identify which debit types should be included. It also adds a
column to the table in the Debit Types area of System Preferences which shows
which debit types are included. The ability to edit all debit types has been
added rather than just the non-system ones and the flag to include/exclude the
debit type from noissuescharge can be changed by clicking that edit button.
Test plan:
1) Choose a patron and add some fines to this patron that have different debit_types
2) Navigate to system preferences and observe that currently you can only amend
the noissuescharge included debit types using three preferences:
ManInvInNoissuesCharge, RentalsInNoissuesCharge, HoldsInNoissuesCharge
3) Apply both commits attached to this bug
4) Navigate as above and observe that these three system preferences are now gone
5) Navigate to Debit Types in System Preferences, the table should have a column
called No issues charge that shows whether a debit_type is Included or Not
included
6) Click the edit button and there should be a checkbox for Included in
noissuescharge
7) Change some of the debit_types using this option and observe that the patron
you added fines to will either be blocked from checkouts or able to checkout
depending on which debit_types you include and the value of these fines.
Mentored-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds two new API endpoints for fetching a patrons credits and
a patrons debits.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Rollback should really be the last statement.
I am leaving get_from_storage here, but add a comment that it seems
unneeded at this moment. The Koha::Account::Offset->new and
C4::Stats::UpdateStats wont change the line.. But since the distance
in code is becoming a bit larger, I wont complain.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Hooks added:
after_account_action with new action add_credit
How to test:
Run tests in t/db_dependent/Koha/Plugins/Account_hooks.t
Sponsored by: Gothenburg University Library
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When using the "Payout amount" button, accountlines.manager_id is not
populated. This is not the case with the "Issue payout" buttons.
Test Plan:
1) Create a manual credit
2) Issue a payout using the "Payout amount" button
3) Inspect the payout accountline, note it has no manager_id
4) Apply this patch, restart all the things!
5) Repeat steps 1 and 2
6) Note the new payout accountline has a manager_id!
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
JK: Fix commit title
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
SIP00 is the code for CASH transactions that have taken place on a SIP
client. Cash management treats CASH type transactions as a special case
for banking and register requirements. This patch brings SIP00 in line
with the CASH handling code of cash management.
Test plan
1) Enable cash management with 'EnablePointOfSale'
2) Enable cash registers with 'UseCashRegisters'
3) Add a cash register via 'Administration > Cash registers'
4) Make some payments against the ash register in the staff client
5) Attempt to make a payment via a SIP client without having associated
a cash register to the SIP account config
5a) This should now fail
6) Attach the cash register to the SIP account used above
6a) Payment should now work again on SIP transactions
7) Look at the cash register details page for the cash register
7a) 'Bankale' should now include cash from both SIP and Staff client
sales
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
It will conflict with other ->messages methods, it's too generic.
Bug 29230 needs Koha::Patron->messages to return Koha::Patron::Messages for instance.
Test plan:
Confirm that the tests modified by this patch still pass
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
On writing the regression tests, I noticed the CREATE offset was added
to the template. The idea behind passing the offsets is that we can
print information about the lines that got the credit applied. Having
the CREATE offset is meaningless, and (worse) would require users to add
logic to skip it. And all the payment information is already passed in
the 'credit' variable anyway.
This patch filters the credit_offsets by type, leaving the APPLY ones
only.
To test:
1. Apply up to the regression tests
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/Account.t
=> FAIL: 3 offsets, including the CREATE one, boo!
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass! Only the two APPLY offsets are returned!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The bug here was worse than originally thought. We were calling the
wrong relation too.. we should probably add some exceptions to catch
this, it confuses me every single time!
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Being based on _new_from_dbic (discussion on bug 28883), makes the
assignment incorrect:
my @account_offsets = $payment->debit_offsets;
This patch explicitly makes the resultset be assigned as a list by
calling *as_list*.
To test:
1. Have UseEmailReceipts disabled
2. Have a patron with a debt of 6
3. Make a payment of 2
=> SUCCESS: All good
4. Enable UseEmailReceipts
5. Repeat 3
=> FAIL: You get something like:
ERROR PROCESSING TEMPLATE: undef error - The method Koha::Account::Offsets->debit is not covered by tests!
Trace begun at /kohadevbox/koha/Koha/Objects.pm line 595
Koha::Objects::AUTOLOAD('Koha::Account::Offsets=HASH(0x561cbe2ac930)') called at input text line 6
eval {...} at input text line 6
eval {...} at input text line 23
6. Apply this patch
7. Repeat 3
=> SUCCESS: It doesn't explode anymore!
8. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The history view of an accountline shows increases and decreases in the
amount outstanding from the perspective of the credit/debit line you are
inspecting.
Apply creates a negative offset amount which acts to 'reduce' both the
outstanding 'debt' for the debit line and the outstanding 'credit' for
the credit line. Starting with a negative offset for the credit thus
makes this nonsenical.
Void creates positive offset amounts which act to 'restore' both the
outstanding 'debt' for the debit line and the outstanding 'credit' for
the credit line.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch updates the Koha::Account methods for adding debits and
credits to use the 'CREATE' offset type for the creation record.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
On bug 17591 we discovered that there was something weird going on with
the way we export and use subroutines/modules.
This patch tries to standardize our EXPORT to use EXPORT_OK only.
That way we will need to explicitely define the subroutine we want to
use from a module.
This patch is a squashed version of:
Bug 17600: After export.pl
Bug 17600: After perlimport
Bug 17600: Manual changes
Bug 17600: Other manual changes after second perlimports run
Bug 17600: Fix tests
And a lot of other manual changes.
export.pl is a dirty script that can be found on bug 17600.
"perlimport" is:
git clone https://github.com/oalders/App-perlimports.git
cd App-perlimports/
cpanm --installdeps .
export PERL5LIB="$PERL5LIB:/kohadevbox/koha/App-perlimports/lib"
find . \( -name "*.pl" -o -name "*.pm" \) -exec perl App-perlimports/script/perlimports --inplace-edit --no-preserve-unused --filename {} \;
The ideas of this patch are to:
* use EXPORT_OK instead of EXPORT
* perltidy the EXPORT_OK list
* remove '&' before the subroutine names
* remove some uneeded use statements
* explicitely import the subroutines we need within the controllers or
modules
Note that the private subroutines (starting with _) should not be
exported (and not used from outside of the module except from tests).
EXPORT vs EXPORT_OK (from
https://www.thegeekstuff.com/2010/06/perl-exporter-examples/)
"""
Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access it’s members.
@EXPORT and @EXPORT_OK are the two main variables used during export operation.
@EXPORT contains list of symbols (subroutines and variables) of the module to be exported into the caller namespace.
@EXPORT_OK does export of symbols on demand basis.
"""
If this patch caused a conflict with a patch you wrote prior to its
push:
* Make sure you are not reintroducing a "use" statement that has been
removed
* "$subroutine" is not exported by the C4::$MODULE module
means that you need to add the subroutine to the @EXPORT_OK list
* Bareword "$subroutine" not allowed while "strict subs"
means that you didn't imported the subroutine from the module:
- use $MODULE qw( $subroutine list );
You can also use the fully qualified namespace: C4::$MODULE::$subroutine
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch restores the behaviour ->pay always acting as though
`AccountAutoReconcile` was enabled.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch fixes the tests for when a negative amount is passed to the
pay method. Prior to now, a negative amount would have been passed
through and recorded. This was inconsistent with all other accounts
methods and has been deprecated to ensure consistent amounts handling.
This patch also introduces basic validation to prevent negatives being
entered into the UI.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch is an interim patch to update Koha::Account->pay to use the
new Koha::Account->payin_amount method internally. It simply utilises
that method for the logic and acts as an input/output shim for
compatability and to allow us to use the existing tests.
Test plan
1/ Run t/db_dependent/Koha/Account.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a `payin_amount` method to the Koha::Account as a modern
replacement to the `pay` method.
The new method uses the `add_credit` and `Koha::Account::Line->apply`
methods internally for consistency and returns the created credit
Koha::Account::Line result.
Test plan
1/ Run t/db_dependent/Koha/Account.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The tests did not include testing for offset lines. This patch adds such
tests and updates the function to pass them
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Tomas pointed out that we could, and probably should, use the internal
'add_debit' method within this function.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a 'payout_amount' method to the Koha::Account class to
allow payout of an amount against a list of credits (or any outstanding
credits, oldest to newest).
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It's a boolean, it must be named is_*
Test plan:
Confirm that
prove t/db_dependent/Koha/Account/Line.t
is still returning green
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
These patches are making the call for an amount match the call for a specific line,
we should also match the passing of interface to ensure the correct pref is checked
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There are a few cases where the `renew_item` method in
Koha::Account::Line will return `undef`. For these cases, we should not
pass the error up the chain to the controllers as it leads to malformed
error messages in the UI.
Test plan
1 - Make sure FinesMode is on, RenewAccruingItemWhenPaid is off
2 - Checkout an item to a patron and make it overdue (can backdate the
checkout)
3 - Make sure the itemtype has fines that will be charged
4 - Charge the fines:
Set finesMode = production
perl misc/cronjobs/fines.pl -v
5 - Check the fine appears on the patrons account
6 - Pay off the fine
7 - Receive alert after payment that reads: "The fines on
the following items were paid off, renewal results are
displayed below:
No title ( ): Not renewed - Unknown error"
8 - Apply the patch
9 - Repeat steps 1 through 6 and note that you no longer trigger the
error message.
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch ensures we can uniquely identify automatic overpayment refund
credits from the accountlines by introducing a new account credit type
and adding appropriate translations for the new code.
Test plan
1/ You'll need an overpayment refund to start...
1a/ Issue yourself and item and set the date due early enough
to create an overdue fine for at least 2 days worth of overdue fines
1b/ Run the fines.pl script to add the fines
1c/ As a patron, pay off the accruing fine
1d/ Return the item ensuring you backdate it at least a day
1e/ Check that there is an 'Overpayment refund' credit on the patrons
account.
2/ Check that the overpayment string is translatable (i.e. it appears in
the accounts include file)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Currently, Koha::Account::pay will fail if no user is logged-in when it is
called.
In this case, this patch will use undef instead of 0 for $manager_id in order
to comply with the foreign key constraint on manager_id.
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Biblibre and Libriotech have created a OPAC payment plugin that was
having problems because of this bug. Applying the fix in this patch
to a live server solved the problem.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
t/db_dependent/Koha/Account/Line.t .. 8/12 # Looks like you planned 16 tests but ran 3.
# Failed test 'void() tests'
# at t/db_dependent/Koha/Account/Line.t line 723.
Undefined subroutine &Koha::Account::UpdateStats called at /kohadevbox/koha/Koha/Account.pm line 289.
It's certainly caused by a circ dep from
commit 5ce968e0e5
Bug 24151: Copy info to the pseudonymized table when a transaction is done
See also bug 17600 for more context.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds the same updated logic as found in
Koha::Account::Line->apply to handle LOST_FOUND credits being applied
against their associated LOST debit.
Currently a 'LOST_FOUND' credit is never created via the pay method and
so the additional test will always pass, but the addition here accounts
for possible future uses.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Some rebase issues, accounttype no longer exists, circ rules make
CanBookBeRenewed fail, so we mock that too
interface must be passed as a hashref
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Rebasing was a nightmare, so I'm squashing the sign off follow-ups to
ease the pain with any future rebases
Includes:
Bug 23051: (follow-up) Refactor renewal code
As per Nick's first point in comment #20, the code that tests for
renewability and renews items has been refactored into it's own
function.
Bug 23051: (follow-up) Provide feedback
For renewals that fail when a fine is being paid off, this patch causes
any errors to be passed back to the template for display.
Addresses the second point in Nick's comment #20
Bug 23051: (follow-up) Fix unit tests
As raised by Nick in comment #35
Bug 23051: (follow-up) Fix/improve feedback
This follow up patch addresses the following parts of Nick's feedback in
comment #35:
- it would be nice to get feedback on what was successfully renewed as well
- In general I think I would prefer to see 'ok' and 'not_ok' returned as
a single 'renewal_results' array
- There is no listing of errors if I use the 'pay' button on an
individual fine
Bug 23051: (follow-up) Refactor methods
This follow up patch addresses the following parts of Nick's feedback in
comment #35:
- I don't really like that the functions are internal functions and then
exported
- I think the pref description should highlight that if 'RenewalPeriodBase'
is set to due date, there may be doubled charges
Bug 23051: (follow-up) Add SIP summary
This follow up patch addresses the following parts of Nick's feedback in
comment #35:
- Ideally SIP would get feedback in a screen message
Bug 23051: (follow-up) Renewing in OPAC
This follow up patch addresses the following parts of Nick's feedback in
comment #35:
- I am also not sure about the code path if a patron paid fines on the
opac (via paypal etc.) but renewals are not allowed on the opac.
We've introduced the syspref RenewAccruingItemInOpac (default is off)
which, when enabled, will cause items attached to fines that are paid
off in the OPAC (via payment plugins), to be automatically renewed.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Jonathan Druart
Olivia Reynolds
Tomas Cohen Arazi
PerplexedTheta
Koha Development Team
Emily Lamancusa
Martin Renvoize
Marcel de Rooy
Emmi Takkinen
Lucas Gass
Matt Blenkinsop
Stefan Berndtsson
Aleisha Amohia
Kyle Hall
Nick Clemens
Matthias Meusburger
Andrew Isherwood