When a single-register cashup is completed from the Cash summary page
(registers.pl), pos/register.pl redirected back to registers.pl without
the '#cashup-<id>' hash, so the hash-watcher in registers.tt never
triggered the cashup summary modal. Completing the same cashup from the
Transaction history page (register.pl) worked because that branch
already appended the hash.
Append '#cashup-<id>' to the registers.pl redirect URL too, so both the
'Record cashup' (quick) and 'Complete cashup' (two-phase) actions on the
Cash summary page open the summary modal on return.
Test plan:
1. Have at least one register with cash transactions.
2. From Cash summary (registers.pl), click 'Record cashup' on a register
with no cashup in progress; complete it.
=> On return, cashup summary modal opens automatically.
3. Start a two-phase cashup; from Cash summary click 'Complete cashup'
and confirm.
=> On return, cashup summary modal opens automatically.
4. From Transaction history (register.pl), complete a cashup as before.
=> Modal still opens (regression check).
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: Jackie Usher <jackie.usher@westsussex.gov.uk>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This patch implements an optional two-phase cashup workflow for point
of sale operations, along with improved error handling and validation.
Two-Phase Cashup Workflow:
- Staff can initiate cashup (CASHUP_START) and complete later
- Prevents new transactions on registers with cashups in progress
- Tracks cashup sessions with start/end timestamps
- Supports both quick cashup (immediate) and staged cashup workflows
- Updates batch cashup workflow operations across multiple registers
Error Handling & Validation:
- Centralized exception handling for cashup operations
- Clear validation messages for missing parameters
- Prevents cashup when no cash transactions exist
- Improved handling of zero/negative amounts
- Informative error messages for user guidance
Negative Amount Support:
- Supports negative cashup amounts for cashup deficits
- Automatic detection when actual cash is less than expected amount
- Creates appropriate CASHUP_DEFICIT records
- UI handles both positive and negative reconciliation amounts
- Updated calculations and display logic throughout
Modal Refactoring:
- Eliminates code duplication between register.tt and registers.tt
- Centralized cashup modal functionality in cashup_modals.js
- Shared confirm_cashup.inc and trigger_cashup.inc templates
- Consistent user experience across all cashup workflows
- Improved maintainability and code organization
Backend changes (Koha::Cash::Register):
- start_cashup(): Creates CASHUP_START action to begin session
- cashup_in_progress(): Detects active cashup sessions
- add_cashup(): Enhanced with two-phase completion support
- outstanding_accountlines(): Respects cashup session boundaries
Frontend changes:
- Interactive modals for starting and completing cashups
- Real-time calculation displays
- Support for reconciliation with actual amounts
- Batch operations UI for multiple registers
- Responsive error messaging and validation feedback
Test plan:
1. Apply patches and restart services
2. Run prove t/db_dependent/Koha/Cash/Register.t
3. Run prove t/db_dependent/Koha/Cash/Register/Cashup.t
4. Test single register workflows:
- Start cashup, add transactions, verify blocked
- Complete cashup with reconciliation amounts
- Test with positive, negative, and zero amounts
5. Test multi-register workflows:
- Select multiple registers on registers page
- Perform batch cashup operations
- Verify each register processes correctly
6. Test error conditions:
- Attempt cashup with no transactions
- Attempt cashup with invalid amounts
- Verify clear error messages displayed
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: Jackie Usher <jackie.usher@westsussex.gov.uk>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
The previous patch hides the 'Account credit' option in the refund modal
when the accountline has no borrowernumber, but that is a UI convenience
only. A crafted POST (or a stale page) could still submit
refund_type=AC against an anonymous accountline, which would create a
REFUND credit with no patron to attach it to and leave the register
unbalanced because the payout branch is skipped.
Add a server-side guard in pos/register.pl that refuses the operation
and surfaces a new error_refund_anonymous_ac flag, rendered in
pos/register.tt in the same style as the other refund errors.
Test plan:
1. Apply the patch
2. Log in as a user with cash_management/anonymous_refund permission
3. Record an anonymous sale against a register
4. Using the browser devtools (or curl), POST to pos/register.pl with
op=cud-refund, refund_type=AC and the accountline id of the sale
5. => Confirm the request is rejected and the
"Account credit refunds are not available for anonymous transactions"
message is shown
6. => Confirm no REFUND accountline was created and the register
balance is unchanged
7. Repeat the POST with refund_type=CASH (or any non-AC type) and
confirm the refund + payout are created normally
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
When processing a refund through the POS register with refund type 'AC'
(Account Credit), the system was incorrectly creating both a REFUND credit
and a PAYOUT debit with payment_type = 'AC'.
When 'AC' is selected, the refund should remain as a credit on the patron's
account without creating a payout. This behavior was already correct in the
member account refund workflow (members/boraccount.pl) but was missing
from the POS refund workflow.
This patch:
1. Adds the same check to pos/register.pl that exists in members/boraccount.pl
to skip payout creation when refund_type is 'AC', making both workflows
consistent.
2. Fixes the JavaScript in register.tt to properly hide the 'AC' option for
anonymous transactions. The original check only tested for empty string,
but borrowernumber can be undefined/null, which needs to be handled.
Test plan:
Part 1: Test patron transaction refund with Account Credit (AC)
1. Find or create a test patron
2. On the patron's Accounting tab, manually add a charge (e.g., Manual fee)
3. Pay the fee off from the patron's Accounting tab
4. Navigate to Point of Sale > Transaction History
5. Find the payment transaction you just created
6. Click "Issue refund" on the payment line item
7. Verify that "Account credit" appears as an option in the "Transaction type"
dropdown
8. Select "Account credit" as the transaction type
9. Enter the refund amount and click "Confirm"
10. Navigate back to the patron's Accounting tab
11. Verify that a REFUND credit appears on their account
12. Verify that NO PAYOUT debit was created
13. Verify the credit remains on the patron's account (positive balance)
Part 2: Test patron transaction refund with Cash payout
16. Using the same patron, create another manual fee and payment
17. Navigate to Point of Sale > Transaction History
18. Click "Issue refund" on the new payment
19. Select "Cash" (or another payment type) as the transaction type
20. Enter the refund amount and click "Confirm"
21. Navigate back to the patron's Accounting tab
22. Verify both a REFUND credit and a PAYOUT debit appear
23. Verify the PAYOUT has the correct payment_type (e.g., CASH)
Part 3: Test anonymous transaction (no Account Credit option)
24. Navigate to Point of Sale
25. Add an item to sell and complete the payment
27. Navigate to Point of Sale > Transaction History
28. Find the anonymous payment you just created
29. Click "Issue refund" on the payment line item
30. Verify that "Account credit" does NOT appear in the "Transaction type"
dropdown (only payment types like Cash, Check, etc. should appear)
31. This confirms anonymous transactions cannot have account credits since
there's no patron account to credit
Expected results:
- Patron transactions show "Account credit" option in refund dropdown
- Anonymous transactions do NOT show "Account credit" option
- AC refunds create only REFUND credit (no PAYOUT debit)
- Non-AC refunds create both REFUND credit and PAYOUT debit
- Run: prove t/db_dependent/Koha/Cash/Register/Cashup.t
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
The previous approach triggered popup blockers because the receipt window
was opened via JavaScript after a page reload — browsers treat this as a
non-user-initiated action. This patch reverses the flow: when
FinePaymentAutoPopup is enabled, the payment form submits directly to a
new tab via target="_blank" (a user-initiated action that browsers allow),
the server processes the payment and redirects (303) to the receipt page,
which auto-prints and closes itself, returning focus to the POS tab.
When FinePaymentAutoPopup is disabled, the server redirects back to the
POS page with payment details in the URL (standard PRG), displaying the
existing success banner with print/email receipt buttons.
Changes:
- pos/pay.pl: Implement PRG redirect for both popup and non-popup flows,
URI-encode redirect parameters, remove session-based state management
- pos/pay.tt: Add target="_blank" when FinePaymentAutoPopup is enabled,
reset form state after submission via same-scope setTimeout
- pos/printreceipt.pl: Add error handling for missing receipts, pass
autoprint parameter to template
- pos/printreceipt.tt: Add conditional auto-print, manual print/close
buttons, error display, and IntranetSlipPrinterJS preference support
- slip-print.inc: Modernize jQuery to vanilla JS, remove obsolete
Chrome setTimeout hack
Test plan:
1. Enable FinePaymentAutoPopup system preference
2. Go to Point of Sale, add items, and complete a sale
3. Verify receipt opens in a new tab without popup blocker warnings
4. Verify receipt auto-prints and tab closes after printing
5. Verify original POS tab form is reset for next transaction
6. Disable FinePaymentAutoPopup
7. Complete another sale
8. Verify POS page shows success with Print/Email receipt buttons
9. Test receipt printing from other pages (circulation, fees) to
confirm slip-print.inc change causes no regressions
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
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 receipt printing logic was failing because it always expected a credit
but the "Print receipt" button was passing the payout debit line ID.
This fix:
- Updates pos/printreceipt.pl to use previously added PAYOUT template based
on account line type
- Uses RECEIPT template for credits, PAYOUT template for PAYOUT debits
- Throws proper error for unsupported transaction types
Test plan:
1. Make a purchase through Point of Sale
2. Go to transaction history for the register used
3. Issue a refund for the purchase
4. Click "Print receipt" button for the refund
5. Verify receipt prints correctly with payout details
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
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>
This patch fixes two issues with cash refunds on the register page:
1. Payouts were not appearing in the transactions table after being
created because accountlines were fetched before the refund
operation completed.
2. Account credit (AC) refunds were incorrectly creating payout
transactions when no cash should leave the register.
Changes:
- Only create payout for non-AC refund types
- Use explicit registerid from page context for payout
- Add POST/REDIRECT/GET pattern after refund to refresh page data
- Add client-side validation for cash register requirement on patron
account page
Test plan:
1. Navigate to POS register page with transactions
2. Issue a cash refund on a transaction
3. Verify the payout appears in the transactions table
4. Issue an account credit (AC) refund
5. Verify no payout is created (only the refund credit)
6. On patron account page, attempt cash refund without register
7. Verify validation message appears
Signed-off-by: Jackie Usher <jackie.usher@westsussex.gov.uk>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
The upstream implementation of POST/REDIRECT/GET pattern for cashup operations
introduced a regression where the cashup modal would no longer auto-trigger
after successful cashup submission. The original approach passed cashup_id as
a query parameter in the redirect, but the template variable was not being
populated from the URL parameter, causing the JavaScript to receive an empty
value.
This follow-up implements a more modern and reliable solution using URL hash
fragments instead of query parameters:
1. Changed redirect URLs to use hash fragments (e.g., #cashup-123)
2. Updated JavaScript to detect and parse hash fragments on page load
3. Auto-triggers the cashup modal when hash is present
4. Cleans up the URL using history.replaceState() after modal opens
Benefits:
- Maintains proper POST/REDIRECT/GET pattern
- Hash fragments don't trigger server requests or require server-side handling
- More reliable than template variable approach
- Follows modern web development patterns
- Works consistently across both register.pl and registers.pl pages
Test plan:
1. Navigate to POS register page (pos/register.pl)
2. Perform a cashup operation
3. Verify the cashup summary modal automatically appears after redirect
4. Verify the URL is clean (no hash fragment visible)
5. Repeat for registers summary page (pos/registers.pl)
6. Perform individual register cashup
7. Verify modal auto-triggers correctly
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch automatically triggers the cashup display modal after a
cashup is performed from the Cash registers summary page when performing
a cashup on an individual register.
Test plan:
1. Enable the point of sale system preference
2. Ensure you have permission for cash_management > cashup
3. Create at least one cash register for your current branch
4. Navigate to More > Point of Sale > Cash registers
5. Perform some transactions to create outstanding amounts
6. Click 'Record cashup' button on an individual register
7. Confirm the cashup in the modal dialog
8. Verify that after page reload, the cashup summary modal
automatically opens showing the details of the cashup just performed
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch automatically triggers the cashup display modal after a
cashup is performed from the individual Register details display page.
Test plan:
1. Enable the point of sale system preference
2. Ensure you have permission for cash_management > cashup
3. Create at least one cash register for your current branch
4. Navigate to More > Point of Sale > Cash registers
5. Click on a register name to access the individual register page
6. Perform some transactions to create outstanding amounts
7. Click 'Record cashup' button on the register details page
8. Confirm the cashup in the modal dialog
9. Verify that after page reload, the cashup summary modal
automatically opens showing the details of the cashup just performed
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Sally Healey <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The cashup functionality on both /pos/register.pl and /pos/registers.pl
pages was using GET requests via anchor tags, which could cause
duplicate cashup records when users refreshed the page after performing
a cashup.
This patch implements proper POST/REDIRECT/GET pattern with CSRF
protection:
1. Convert anchor tag buttons to proper HTML forms with submit buttons
2. Add CSRF token protection to all cashup operations
3. Change operation from 'cashup' to 'cud-cashup' for CSRF compliance
4. Implement redirects after successful cashup operations to prevent
resubmission
5. Update JavaScript to populate form fields instead of href attributes
This ensures cashup operations follow HTTP semantics properly (POST for
state changes) and prevents duplicate submissions while maintaining the
existing user experience.
Test plan:
1. Apply patch and restart services
2. Go to Point of Sale > Cash registers
3. Click "Record cashup" on any register - should open modal
4. Click "Confirm" - should perform cashup and reload page
5. Refresh the page - should NOT create duplicate cashup record
6. Go to Point of Sale > Register for individual register
7. Click "Record cashup" - should open modal
8. Click "Confirm" - should perform cashup and reload page
9. Refresh the page - should NOT create duplicate cashup record
10. On registers page, try "Cashup all" button - should work correctly
11. Verify all existing functionality (modals, summaries) still works
12. Check browser developer tools - all requests should be POST for
cashup operations
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>
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>
"One Ring to rule them all, one Ring to find them, One Ring to bring
them all and in the darkness bind them"
We've been battling against this for years, with a mixed use of
terminology and thus confusion in templates vs controllers and notice
templates. I've decided to just try and make sure all the terminology
matches throughout, and use the more popular 'tendered' term over the
'collected' term.
This patch standardizes the terminology used throughout the payment
system to consistently use 'tendered' instead of the mixed usage of
'collected' and 'tendered' that has caused confusion over the years.
Changes include:
- Update all payment form templates to use 'tendered' input names
- Update JavaScript validation and change calculation logic
- Update controller parameter handling in pos/pay.pl, pos/printreceipt.pl,
and members/paycollect.pl
- Update sample notice templates (RECEIPT) to use 'tendered' variable
- Add null check for $total_tendered to prevent perl warnings
Test plan:
1. Test Point of Sale payments with tendered amounts and change calculation
2. Test member account payments with tendered amounts
3. Test receipt generation (both print and email)
4. Verify JavaScript validation works correctly
5. Confirm no perl warnings when tendered amount is undefined
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>
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>
To test:
1. Enable EnablePointOfSale and UseCashRegisters system preferences in Koha Administration -> Global system preferences
2. Go to Koha Administration -> Cash registers and add a new cash register
3. Go to Koha Administration -> Debit types and add a new debit type. Make sure you check the 'can be sold' option
4. Go to Point of sale
5. Select Add for your item under Items for purchase
6. Fill in Collect payment box and click Confirm
7. When payment is received, click Print receipt
8. Confirm your format settings for RECEIPT are applied
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To recreate:
1. Enable the "EnablePointofSale" syspref.
2. Set the "UseCashRegisters" syspref to use.
3. Create 3 new registers (Register A, B and C) with a float amount of $25.
4. Under POS, configure 3 new debit types (i.e. Copies, Earbuds, Friends Donation)
-- You can leave the default amounts blank, or add an amount if desired.
-- Set "Can be manually invoiced?" and "Can be sold?"
5. Under point of sale make a $5 sale of copies under Register A.
6. Under point of sale make a $10 sale of earbuds under Register B.
7. Under point of sale make a $100 sale of Friends Donation under Register C.
8. At circ/set-library.pl set your register to Register A.
9. Go back to POS and view the "Transaction history for Register A" - it shows the correct amount of $5 sold in copies.
10. Go back to circ/set-library.pl and change your register to Register B.
11. Go back to POS and view the "Transaction history for Register B" - it shows the incorrect transaction history. It is showing the transaction history for Register A.
12. Go back to circ/set-library.pl and change your register to Register C.
13. Go back to POS and view the "Transaction history for Register C" - it shows the incorrect transaction history. It is showing the transaction history for Register A.
14. Apply patch, repeat. The correct transactions should now show.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds the ability to use email receipts with the point of sale
module.
To test:
1) Configure your Koha to enable the point of sale system.
2) Add an email template to the 'Point of sale > RECEIPT' notice.
3) Add some charges on point of sale and pay for them.
3a) You should now see a new 'Email receipt' button next to the 'Print
receipt' option.
3b) Clicking the button will display a modal to enter the anonymous
users email address
3c) Enter an email address and confirm to send the email
Sponsored-by: Martin Renvoize <martin.renvoize@gmail.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The idea rely on the KohaDates TT plugin for the date formatting. We
should not have any output_pref calls in pl or pm (there are some
exceptions, for ILSDI for instance).
Also flatpickr will deal with the places where dates are inputed. We
will pass the raw SQL value (what we call 'iso' in Koha::DateUtils), and
the controller will receive the same value, no need to additional
conversion.
Note that DBIC has the capability to auto-deflate DateTime objects,
which makes things way easier. We can either pass the value we receive
from the controller, or pass a DT object to our methods.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch changes the fix from adding a day to setting the time to
23:59:59.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Test Plan:
1) Sell an item
2) Cash up to make the sale historical
3) Search "Older transactions" with both dates being the current date,
click "Display" to search
4) Note you get no results
5) Apply the patch
6) You should now see your transaction
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch converts the point of sale receipt printer controller to
using GetPreparedLetter instead of calling getletter directly.
Test plan
1. Setup for testing:
i. Enable EnablePointOfSale and UseCashRegisters system preferences
ii. Add a new cash register
(Administration > Accounting > Cash registers)
iii. Add one or two products for sale
(Administration > Accounting > Debit types, make sure 'Can be sold?' is ticked)
2. Go to Home > Point of sale
3. Add some items for purchase to a sale
4. Click confirm
5. Click on 'Print receipt' and save the PDF file somewhere
6. Apply patches
7. Update database: updatedatabase
8. Repeat steps 2-5
9. Compare receipt PDFs - should be no changes
10. Check that the default RECEIPT is updated - for print, HTML should be ticked
11. Sign off!
Signed-off-by: David Nind <david@davidnind.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>
The way we handle notice templates is confusing (see bug 27660, bug 26787, bug 28487).
This patch remove C4::Letters::getletter and use either Koha::Notice::Templates->find
or the newly created methods ->find_effective_template that will do
all necessary to return the correct template.
Test plan:
- Create and modify notice templates
- Make sure you have TranslateNotices turned on and that some notices
templates have a translated version
- Use holds_reminder.pl and overdue_notices.pl cronjobs and confirm that
the generated notices are the expected ones
- Test also pos/printreceipt.pl
- And finally test some other notices (CHECKIN, RENEWAL for instance)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
[EDIT] Amended by removing comment for $params={%$params}
JD amended patch:
* Add missing POD
* Fix spelling (dont ==> don't)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This adds a fallback for when a payment is made anonymously to allow
printing a receipt in the staff members current session language.
Test plan
1. Set `EnablePointOfSale` and `UseCashRegisters`
2. Add new cash register`
3. New debit type that 'can be sold'
4. Make a sale (via Point of Sale) using the above debit type.
5. Attempt to 'print receipt' from the subsequent prompt
6. Not the ISE: Can't call method "lang"
7. Apply patch
8. Attempt to 'print receipt' again, this time it should work.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The filter for only displaying un-archived debit types on the point of
sale page had been missed.
NOTE: It would be beneficial to move this to a default filter in the
Koha:: objects search method for both debit_types and credit_types.. but
I opted for the quick fix here to resolve the bug and will impliment
default filtering in a subsequent enhancement bug.
Test plan
1/ Archive a debit type that is marked as 'Can be sold'
2/ Go to the point of sale page and confirm the above debit type appears
3/ Apply the patch
4/ Confirm the debit type no longer appears in the point of sale page.
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch simplifies the members/print*.pl controller scripts to only
pass around the minimum required data for the templates.
Test plan
Slips should continue to print as they did prior to the patch
1/ Add a manual invoice and manual debit to a patrons account
2/ Print a slip for the manual invoice, compare to a printed slip prior
to the patch.
3/ Print a slip for the manual debit, compare to a printed slip prior to
the patch.
4/ Signoff.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch centralises the payment/transaction type select options
handling so the SIP types are properly in all cases.
Test plan
1) Check that SIP payment types are properly hidden on the following
modals.
1a) Refund modal on the borrower account page (The 'Account credit'
option should appear here)
1b) Payout modal on borrower account page
1c) Payment via paycollect
1d) Payment via point of sale
1e) Refund via point of sale, register details page (The 'Account
credit' option should only appear for debts associated to a patron and
not for payments accepted via point of sale)
2) Signoff
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch simplifies the members/print*.pl controller scripts to only
pass around the minimum required data for the templates.
Test plan
Slips should continue to print as they did prior to the patch
1/ Add a manual invoice and manual debit to a patrons account
2/ Print a slip for the manual invoice, compare to a printed slip prior
to the patch.
3/ Print a slip for the manual debit, compare to a printed slip prior to
the patch.
4/ Signoff.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds handling to allow for the use of the session cash
register by default if it has been set, otherwise it defaults to '--
None --' and requires the end user to select the register to proceed
with the sale.
Test plan
1/ Enable cash registers via the 'UseCashRegisters' system preference
2/ Enable point of sale via the 'EnablePointOfSale' system preference
3/ Navigate to the point of sale page
4/ Note that if you are logged in at a branch with no cash registers yet
defined, then an alert should appear
5/ Note that when you are logged in at a branch with cash regsiters
defined, but without a cash register associated with your session then
the cash 'Cash register' select box is populated with '-- None --' and
you are required to select a register prior to submission
6/ Note that upon selection, the '-- None --' option is disabled
7/ Note that when you have a register associated with your session then
the 'Cash register' select box is pre-populated with that register.
8/ Signoff
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The description of REFUND type accountline credits introduced with the "issue refund" feature is not translatable.
To test:
- Make sure a language with a complete translation is installed
- Switch to the language
- Go to any user account
- Add a manual invoice
- Pay it off fully or partially
- Click on "issue refund"
- Confirm the refund
- Check the description of the line in the patron account is not translated.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It defaults to 0 in get_template_and_user
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>
The cash register summary page for cash management is available for users
with the 'anonymous_refund' or 'cashup' permission and the actions available
are appropriately displayed.
However, the actions are not yet correctly tested for at the server and
so a user may force submit to accomplish the action.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The libraries summary page for cash management is available for users
wit the 'anonymous_refund' permission to allow them to navigate to
alternate cash registers and search for the prior transaction to refund.
However, currently the cashup option appears, and is not blocked at the
server, for all user who may access the page. It should be blocked for
those users without the 'cashup' permission.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a serverside permissions check for the display of the
registers summary page.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It would appear one has to format the dates in the controller rather
than in the template for input fields.. I wasn't aware of this caveat
until now.
Test plan
1/ Prior to applying patch attempt to look at previous transactions
ensuring you enter a 'to' date.
2/ Note a catastrophic failure
3/ Apply patch
4/ Look at the same date range and note you no longer get a failure but
are instead faced with the requested transactions.
5/ Signoff
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 24492 was not correctly rebased after bug 23355 and did not account
for a variable name change in the 'add_cashup' action. This patch deals
with that.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Cashup of a single register was resulting in a redirect to the register
details page. It should return to the branch details page instead.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds a new 'branch details' page to the POS system which
displays a summary of the cash register transactions for a branch
since each register was last cashed up. It also allows for cashing
up individual registers or cashing up all registers at a given branch
in one transaction.
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>
The form element for selectin cash register override at point of sale was
misnamed and as such one could not actually override the cash register.
This patch corrects the form element name and updates the logic very
slighlty to ensure we still fall back to the defualt no the subsequent
page load.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Martin Renvoize
Andrew Fuerste Henry
Tomas Cohen Arazi
Koha Development Team
Aleisha Amohia
Martin Renvoize
Nick Clemens
Jonathan Druart
Kyle M Hall
Isobel Graham
Fridolin Somers