opac-shelves - forms were stateless - changed to GET
sco-main - forms stateless - changed to GET
** untested because sco + auth is broken
smart-rules.tt - JS form template - added placeholder 'cud-' op
ill-requests - added cud- tp ops
** tested comments, but not checkout, simple changes
boraccount - removed repeated op - updated script
patroncards/edit-batch - add placeholder 'cud-' op
patroncards/manage - add placheholder 'cud-' op
elasticsearch/mappings - separate forms - this could use a style follow-up, but makes more sense separate I think
reports/dictionary - stateless - changed to GET
guided_reports_start - stateless - changed to GET
suggestion/suggestion - add placeholder 'cud-' op
inventory - filed bug 36305, needs more handling
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We do not longer need to generate_csrf from pl files
TODO - members/boraccount.tt and sco/sco-main.tt needs to be adjusted
Bug 34478: [TO SQUASH] Remove generate_csrf from pl
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Test plan would have been nioe.
Tested by changing MAX_AGE with suggestions.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch replaces the 'Print' button with a 'Receipt' menu dropdown
exposing 'Print' and 'Email' options when `UseEmailReceipts` is enabled
Test plan
1. Enable `UseEmailReceipts`
2. Navigate to a patron with paid charges
3. Note the new dropdown 'Receipt' menu
4. Confirm 'Print' works as expected
5. Confirm 'Email' works as expected
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
On bug 29844 we decided to remove wantarray from Koha::Objects->search.
Reviewing the difference occurrences I found some unnecessary uses of ->as_list,
where iterators should be used instead.
This patch only removes the obvious places, not the tricky ones.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
and some more...
There are lot of inconsistencies in our ->search calls. We could
simplify some of them, but not in this patch. Here we want to prevent
regressions as much as possible and so don't add unecessary changes.
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>
This patch removes a noisy warning found in production logs.
To test:
1. Run:
$ tail -f /var/log/koha/kohadev/plack-intranet-error.log
2. Open the 'Accounting' tab for a patron, then click on 'Transactions'
=> FAIL: You see this kind of warning in the logs:
[WARN] CGI::param called in list context from...
3. Apply this patch
4. Repeat 2 (change tab and go back)
=> SUCCESS: No more warning!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
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>
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>
There is a "debug" parameter we are passing from the controller scripts
to C4::Auth::get_template_and_user, but it's not actually used!
Test plan:
Confirm the assumption
Review the changes from this patch
Generated with:
perl -p -i -e 's#\s*debug\s*=\>\s*(0|1),?\s*##gms' **/*.pl
git checkout misc/devel/update_dbix_class_files.pl # Wrong catch
+ Manual fix in acqui/neworderempty.pl
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds double-entry accounting to the Koha::Account::Line->void method.
This results in the addition of a VOID debit type line that is offset
against the original credit type line that is being voided. This allows
us to accurately record when the void took place, at what branch and by
whome the void was triggered.
Test plan
1/ Apply the database update
2/ Add some debts to a borrower account
3/ Pay those debts
4/ Void the payment
5/ A new 'VOID' line should appear on the account for the full amount of
the original payment.
6/ Payments should have all been reversed
7/ t/db_dependent/Koha/Account/Line.t should still pass
8/ Signoff
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan
1/ Add some debts and credits to a patrons account, resulting in an
overall credit
2/ Note the appearance of a 'Payout amount' button next to the total due
line.
3/ Try paying out an amount with the button
4/ Signoff
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>
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>
There is already a button to void a payment. It should be possible to
cancel a charge too.
This patch adds a button in patron's accounting section (Transactions
tab) that allow to cancel charges.
Charges that have been fully or partially paid cannot be cancelled.
It also fixes Koha::Account::Line::is_credit by looking at
credit_type_code instead of amount (amount can be 0 for voided payments)
It also fixes the tests for Koha::Account::Line::void when database does
not contain the borrowernumber 51 (the default in
t::lib::Mocks::mock_userenv)
Test plan:
1. Go to a patron's accounting section
2. Create a manual invoice
3. In Transactions tab, you should see a 'Cancel charge' button. Click
on it. It should now be marked as cancelled
4. Create another manual invoice
5. Pay it (partially or fully)
6. Notice that the 'Cancel charge' button is not available
7. Void the payment
8. 'Cancel charge' button is available again. Click on it and verify
that it still works
9. prove t/db_dependent/Koha/Account/Lines.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: David Nind <david@davidnind.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 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 refund or payout action.
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>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
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>
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>
This patch adds the ability to apply discounts to existing patron
charges from the boraccount page.
Test plan
1/ Carry out some accounting actions that end up with debts on the
patron record. (Add a manual invoice for example)
2/ Note a new 'Apply discount' action button on the unpaid debt
3/ Paid debts do not display the action button
4/ Click the button
5/ Enter an amount into the resulting modal and click confirm
6/ Confirm that the outstanding debt has been reduced by the amount you
specified.
7/ Confirm that a new 'Discount' line appears on the patrons account
8/ Confirm that in the 'details' view of the debt that the discount line
was used against the debt to create the reduction.
9/ Signoff
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This enhancement adds a refined workflow to allow librarians
to refund payments to patrons and record these refunds on the
patrons account.
The use case is that a patron has paid for something before
then performing an action that may require some level of refund
to be actioned. Perhaps they are returning a lost and paid for
book.
Test plan:
1) Undertake a series of transactions that result in a debit
accountline being partially or fully paid off.
2) Note that a new 'Issue refund' button appears next to a
debit (but only if your user has the refund permission or
is a superlibrarian)
3) Click the 'Issue refund' button and a modal should appear
pre-populated with the amount - amountoutstanding.
4) You should be able to edit the amount you wish to refund,
record the refund or cancel.
5) Signoff
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This enhancement adds a refined workflow to allow librarians to pay out
money to patrons and record these payouts on the patrons account.
The use case is that a patron has somehow accrued credit, through a
refund perhaps, and the library wants to be able to physically hand over
some money to balance the patrons account.
Test plan:
1) Undertake a series of transactions that result in some outstanding
credit on a patrons account.
2) Note that a new 'Issue payout' button appears next to a credit with
an outstanding balance (but only if your user has the payout
permission or is a superlibrarian)
3) Click the 'Issue payout' button and a modal should appear
pre-populated with the amountoutstanding.
4) You should be able to edit the amount you wish to payout, make
payment or cancel.
5) Signoff
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>
Some libraries would like to show the amount of change given on print reciepts triggered by FinePaymentAutoPopup
so the patron can verify he or she has recieved the correct amount of change.
1) Apply this patch
2) Edit ACCOUNT_CREDIT slip and add "[% IF change_given %]<h1>CHANGE: [% change_given %]</h1>[% END %]" at the top
3) Enable FinePaymentAutoPopup
4) Make a payment
5) Note the change given is shown on the popup receipt
6) Note the change given is *not* shown on subsequent prints of the same receipt using the "print" button for the payment
Signed-off-by: Kyle Hall <kyle@bywatersolutions.com>
Signed-off-by: Hasina Akhte <hasinaa@pascolibraries.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Some libraries would like an auto-popup after making a payment so librarians don't have
to navigate to the accounts page, locate the new payment, then click the print button.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Make a payment, note no difference in behavior
4) Enable the new syspref FinePaymentAutoPopup
5) Make a payment, note the popup for the payment receipt
Signed-off-by: Lisette Scheer <lisettes@latahlibrary.org>
Rescued-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Changes:
- Replace getting preference ExtendedPatronAttributes by Koha.Preference
in templates
- Add Koha::Patron->attributes for getting patrons extended attributes
- Use this method in circ-menu.inc
- Remove getting attributes from members perl scripts
Test plan:
0) Apply the patch
1) Add some patron attributes type - with free text, authorised value,
limited by libraries...
2) Add some values to this attributes for some patrons
3) Go through as many patron pages as you can and confirm that
attributes are shown at side panel when they shoul and are not shown
when they should not be shown
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
[EDIT] Removed Koha/Schema/Result/BorrowerAttribute.pm
[EDIT] Added missing semicolon on L114 in Koha/Patron/Attribute.pm
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The actions_col template param requires a DB search, only to display the
'Actions' column header vs. an empty string. But there will always be
buttons in there, that were added *after*.
It made sense when only the 'Reverse' button was displayed, but now both
'Print' and 'Details' are displayed anyway.
This patch removes it for good :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Before this patch the Void button didn't appear.
After this patch the Void button appears on payments.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test Plan:
1) Apply this patch
2) Note all references to reversing payments have been removed
3) Note ability to void payments remains unchanged
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Code and variables to deal with the update child feature are not
centralized but copied/pasted in several scripts. Which leads to issues
obsviously (bug 20805 for instance).
Moreover the strings used by the templates are also in several template
files (or .inc)
To deal with that this patch introduces the idea to create 1 .inc file
per .js file
Here we have members-menu.inc for members-menu.js
Test plan:
- Remove all your adult categories (categories.category_type='A')
- Create a patron with a child category
- Try to update to adult category
=> The entry does no longer appears! (This is a change in the behaviour)
- Create one adult category
- Update to adult category
=> There is a JS confirmation message, if you accept the patron will
be updated to the adult category
- Create (at least) another adult category
- Create another child
- Update to adult category
=> No more confirmation message but a popup to select the adult category
- Pick one
=> The patron has been updated to the adult category
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
At this time, only payments may be voided. There is no reason to have this limitation. There are situations where a librarian may need to void an accidental writeoff, or perhaps void an automatic credit that was created by Koha. For illustration, this is directly from a partner library:
"For example a lost book refund becomes a credit on account. Presently the credit may be applied to a fine for a different item charged to patron. We perform a write off to clear the remaining credit, then add the fine back to the account and give the patron a refund for the lost/refunded amount. Our accounting system ask that we keep the Lost funds/refunds separate from all fines."
Test Plan:
1) Create a fine and write it off
2) Note there is no 'void' button for the writeoff
3) Apply this patch
4) Note the buttons now show
5) Test each button on a writeoff
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
We've had the ability to 'reverse' a payment for a long time, but it
would be much better if we had a true void payment function that
replaces the paid amounts into the fee so that it appears as if the
payment was never made.
Test Plan:
1) Apply this patch and dependent patches
2) Run updatedatabase.pl
3) Create some fines
4) Pay those fines
5) Use the new 'void' button to void the payments
6) Note the fines were restored to their pre-payment amounts
Signed-off-by: Koha-us conference <koha-us@koha-us.net>
Signed-off-by: BWS Sandboxes <ByWaterSandboxes@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
Go to the Fines -> Account page of a patron with fees linked to items
--> without patch there is no link to related item
--> with patch the link is presented in description column
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The GetMemberAccountRecords may be a perf killer, it retrieves all the
account lines of a patron and then the related item and biblio
information.
Most of the time we only want to know how much the patron owns to the
library (sum of amountoutstanding). We already have this information in
Koha::Patron->account->balance.
This patch replaces the occurrences of this subroutine by fetching only
the information we need, either the balance, the detail, or both.
It removes the formatting done in the module, to use the TT plugin
'Price' instead.
There is a very weird and error-prone behavior/feature in
GetMemberAccountBalance (FIXME): as the accountlines.accounttype is a
varchar(5), the value of the authorised value used for the
ManInvInNoissuesCharge pref (category MANUAL_INV) is truncated to the 5
first characters. That could lead to unexpected behaviors.
On the way, this patchset also replace the GetMemberAccountBalance
subroutine, which returns the balance, the non issues charges and the
other charges. We only need to have the balance and the non issues
charges to calcul the third one.
Test plan:
Add several fees for a patron and play with HoldsInNoissuesCharge,
RentalsInNoissuesCharge and ManInvInNoissuesCharge.
The information (biblio and item info, as well as the account line) must
be correctly displayed on the different screens: 'Fines' module, fine
slips, circulation module
Note that this patchset could introduce regression on price formatting,
but will be easy to fix using the TT plugin.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Trivial changes here, just do a code review on the QA step
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
When editing adult's info you must see the "Add child" button
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
When you are on a page related to a child you should see the "Update
child to adult patron" button
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Now that we have the 'patron' variable in all our templates, we can call
Koha::Patron->image and do the check from the templates.
Test plan:
On the different pages of the patron module, you should see the default
image if there is no image attached or the one that has been attached
(see pref patronimages)
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In order to simplify and make uniform the code, the controller scripts send
a Koha::Patron object to the templates instead of all attributes of a patron.
That will make the code much more easier to maintain and will be less
error-prone.
The variable "patron" sent to the templates is supposed to represent the
patron the librarian is editing the detail.
In the members module and some scripts of the circulation module, the
patron's detail are sent one by one to the template. That leads to
frustration from developpers (making sure everything is passed from all
scripts) and to regression (we got tone of bugs in the last year because
of this way to do).
With this patch set it will be easy access patron's detail, passing only
1 variable from the controllers.
Test plan:
Play with the patron and circulation module and make sur the detail of
the patron you are editing/seeing info are correctly displayed.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
Login with a patron that is not allowed to see patron's information for patrons
outside of his group. Try to access patron's information from scripts of the patron
module (members/*) and circ/circulation.pl.
You should be able to access patron's information of patrons outside of your group
and get "You are not allowed to see the information of this patron."
If you try and access a patron page with a borrowernumber that does not exist, you
should get "This patron does not exist"
Technical note:
A new C4::Output subroutine is created in this patch: "output_and_exit_if_error"
Executed at the beginning of the script it will permit not to copy/paste all the
different checks to know if the logged in user is authorised to see patron's information.
The design here can be discussed, but I did not find an alternative with as less changes.
On the way I refactor what we did with 'unknowuser' previously: it will now work with all
patron pages, not only the few that used it.
Note that the 'or die "Not logged in";' part should not be needed, but... who trusts
C4::Auth?
I think it could be used as a safeguard later. I am willing to sed and remove them
if required.
Changes in discharge.pl are mainly indentation changes.
With this patch we should now have a $patron variable that refer to the patron we
want to access. That will be very useful to remove plenty of code in members/* and
only pass this variable to the template (instead of 1 variable per patron's attribute).
Signed-off-by: Signed-off-by: Jon McGowan <jon.mcgowan@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
Login with a patron that only have the 'edit_borrowers' permission.
You should be able to access patron's information of patrons inside of your group.
Technical note:
Before this patchset the borrowers permission module contains only 1 permission 'edit_borrowers'.
That meant
borrowers => 1
and
borrowers => '*'
had the same behavior.
Moreover, now that we have 2 permissions, 'CAN_user_borrowers' is set when all
permissions of 'borrowers' are set.
We need to update the different occurrences of these tests.
Signed-off-by: Signed-off-by: Jon McGowan <jon.mcgowan@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test Plan:
Check the following files have been updated from
use strict;
use warnings;
to
use Modern::Perl;
boraccount.pl
default_messageprefs.pl
deletemem.pl
files.pl
mancredit.pl
maninvoice.pl
member-flags.pl
member-password.pl
memberentry.pl
members-home.pl
members-update-do.pl
moremember.pl
notices.pl
pay.pl
paycollect.pl
printfeercpt.pl
printinvoice.pl
printslip.pl
readingrec.pl
routing-lists.pl
setstatus.pl
update-child.pl
Signed-off-by: Jon Knight <J.P.Knight@lboro.ac.uk>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We are passing the Koha::Patron::Category object to the template instead
of the categorycode.
To reproduce this bug you must test in a system which has only one
patron category of the "adult" type. View the details of a patron with a
child-type patron category and choose More -> Update child to adult
patron.
This results in an error:
Can't call method "category_type" on an undefined value at
/home/vagrant/kohaclone/members/update-child.pl line 84.
The URL of the error page shows a problem with the parameters being
passed:
members/update-child.pl?op=update&borrowernumber=12345&catcode=Koha::Patron::Category=HASH(0xa168a18)&catcode_multi=
Test plan:
Make sure you have only 1 adult patron category
Update a child to adult
=> With this patch applied the error is gone and the patron has been
correctly updated
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Patch applies without issue and functions as described.
Signed-off-by: Dilan Johnpullé <dilan@calyx.net.au>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The following warn is triggered when I click the Reverse button next to
an individual payment on the Account tab:
CGI::param called in list context from package
CGI::Compile::ROOT::home_vagrant_kohaclone_members_boraccount_2epl line
63, this can lead to vulnerabilities. See the warning in "Fetching the
value or values of a single named parameter" at /usr/share/perl5/CGI.pm
line 436.
To test:
1) Go to a members detail page in staff side, create a manual invoice,
pay it
2) Go to the Account tab, click Reverse next to the payment you just
made
3) Notice warns
4) Apply patch and repeat steps 1 & 2
5) Warns should be gone
Sponsored-by: Catalyst IT
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
