This appears to be a bug due to inaccuracies in floating point math. I've been unable to reproduce it on demand. Sometimes when using the "Write off selected" button, Koha will give the error that the payment is more than the amount owed, even though they are the same. The solution I've implemented is to move the summation from Perl code to the database query. This video demonstrates the issue and afterward, shows the error goes away after the patch is applied: https://monosnap.com/file/pG69HC7iI9mU9kkuoCtbkVzVTffKlE
Test Plan:
1) Apply this patch
2) Restart all the things!
3) Verify that "Write off selected" functions as usual
Signed-off-by: Amit Gupta <amit.gupta@informaticsglobal.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 new system preference PatronDuplicateMatchingAddFields
to list the patron's attributes to use for deduplication.
The default value is surname, firstname and dateofbirth to keep existing
behaviour.
Test plan:
0. Apply the patch and execute the update DB entry
1. Create a new patron with surname, firstname
2. Create another patron with the same surname, firstname values
=> Confirm you get the duplicate warning
3. Modify the syspref to edit the list of attributes used to dedup
4. Repeat 1 and 2 with different values and confirm that you get the
behaviours you expect
Note: This is only impacting the add patron form from the UI, not the
import patrons tool.
Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We correct the behviour of 'amount' being passed back to the template
and add a work around for the existance of deleted_items alongside a FK
to items in the accountlines table.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch re-arranges the manualinvoice controller script to clarify
code flow, replaces the last call to C4::Accounts::manualinvoice with a
call to Koha::Accounts->add_debit wrapped in a try catch block and also
adds a check on passed barcodes when the invoice type is 'LOST' so it
can link the subsequently created accountline to the item and issue.
Test plan
1/ Add a manual invoice (without entering a barcode)
2/ Add a manual invoice with a valid barcode (Not a LOST type)
3/ Add a manual invoice with a valid, but old, barcode (Not a LOST type)
4/ Add a manual invoice with an invalid barcode, note that an error is
displayed
5/ Add a manual invoice with type 'LOST' and a valid barcode for a
checkout your user has had checked out
6/ Add a manual invoice with type 'LOST' and a valid barcode, but not
one that will match a checkout for your user. Note an error is displayed
7/ When errors are displayed, note the form contains data from the
previous submission so you can just correct the error rather than
re-enter all data.
8/ Signoff
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds "Other" as an option, and also changes the wording of
"None specified" slightly.
To test:
1) Apply the patch
2) Check that there is an "Other" radio button in the patron record, and
that the wording of "None specified" has changed to "None specified /
Prefer not to say".
3) Check that you can save changes to the gender of this patron record,
both on create and modify.
4) Check that these changes also work in the Opac Self-Registration
functionality.
Correct typos in previous commit
Signed-off-by: Devinim <kohadevinim@devinim.com.tr>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a section to the patron details page for listing files
which have been attached to the patron record.
To test, apply the patch and enable the EnableBorrowerFiles system
preference.
- If necessary, attach some files to a patron record by viewing a patron
record and choosing "Files" from the sidebar menu.
- View the detail page (moremember.pl) for a patron who has files
attached.
- You should see a new section under "Alternative contact" with the
heading "Files."
- Test the "Manage" button to make sure it takes you to that patron's
files.
- Confirm that all the attached files are listed.
- Confirm that the links to each file work correctly.
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Barbara Johnson <barbara.johnson@bedfordtx.gov>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
JD amended patch: replace a html filter with uri
Bug 21345: (follow-up) Hide files information if EnableBorrowerFiles is disabled
This patch wraps the new patron file information in a check for the
EnableBorrowerFiles system preference.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Note: I am not confident with this patch, I think it's not polished. I
will not have time to improve it to make it ready for 19.05.00
1. Conflict with bug 20443 (which would have make this change way much
easier!)
2. It does not work :) You will be able to submit the memberentry form
even if the patron attribute is marked as mandatory (??)
3. What about the OPAC?
4. What about repeatable fields? We certainly will need JS code here
5. What about the "Quick add" feature? (I had trouble in the past to not
introduce regression when we played with this template...)
Do not forget to run updatedatabase.pl and regenerate DBIC schema if you
want to play with this patchset.
Signed-off-by: David Nind <david@davidnind.com>
Bug 22844: (follow-up) Make the attribute mandatory when editing a patron
Previous patch forgot the most important, adding the required attribute
to the select/textarea
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
0) Apply the patch
1) Go to all of these pages
Patron detail
Other patron pages - look on the left side (circ-menu)
Patron search
Guarantor search ( go to child patron -> edit -> in guarantor
section click "Set to patron"
Search through "Check out" (in the header)
2) Confirm that does show date of birth and date consistantly,
try it on patrons with and without date of birth set to find
possible reggressions
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
When a user creates a patron's guarantor on /cgi-bin/koha/members/memberentry.pl but doesn't select the relationship from a dropdown, the relationship defaults to first value, which in default sysprefs is "father". This may or may not be correct as this is not a conscious choice from the user.
The solution is to make the "Relationship" field mandatory when there is no empty entry in the system preferences, always starting with an empty option but not allowing the user to save an empty entry.
And if there is an empty option in sysprefs, it allows to save empty, as well as makes it default choice.
To reproduce with default system preferences:
1) Create a new patron who is assumed to have a guarantor or modify the existing one.
2) Under "Guarantor Information" click on "Search to add" button. After performing the search, select a user to act as guarantor. Don't use the dropdown menu to select a relationship. Save your changes.
3) Observe that relationship is set as "father".
4) Apply the patch.
5) Repeat steps 1 and 2.
6) Observe that it doesn't allow you to save the form until you pick a relationship type.
To reproduce with empty entry added to system preferences:
1) Add an empty entry to borrowerRelationship at /cgi-bin/koha/admin/preferences.pl?tab=patrons in Patron relationships section (example: "|father|mother").
2) Create a new patron who is assumed to have a guarantor or modify the existing one.
3) Under "Guarantor Information" click on "Search to add" button. After performing the search, select a user to act as guarantor. Don't use the dropdown menu to select a relationship. Save your changes.
4) Observe that relationship is set as "father".
5) Apply the patch.
6) Repeat steps 1, 2 and 3.
7) Observe when you save the empty entry it does set the relationship as empty.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
- Add a credit to the patron's account
- Make sure they got a pending suggestion
- Try to delete
- Verify you notes for both as list items
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
From the OPAC, add a suggestion
From the staff interface, try to delete the patron who created the
suggestion
=> You get a warning message
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
TEST PLAN:
1. Have a fine on a Patron's account.
2. Choose the "Write off Selected" button
3. Enter an amount less than the amount owed by the patron.
4. Koha will give a yellow box with a note "You must collect a value
greater than or equal to 2.00." The $2.00 is the amount that is
attempted to write off (the amount less than the amount owed).
5. Apply patch
6. Again try to writeoff an amount less than the amount owed.
7. You should be able to write it off.
8. Try paying an amount more than owed, you should still get an
error. You shouldn't be able to write off more than the amount.
9. Follow the above steps via 'Pay selected' as aposed to 'Writeoff
selected'.
10. You should not be able to 'Tender' less than the amount you have
'Paid'.
11. Disable Javascript and run through all the above steps. You should
still be blocked where relevant.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Same as the precedent patch for patron's modification
Test plan is identical but with an existing patron
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This is still not ideal but brings a bit of enhancement.
One possible problem is that the patron creation will fail if the
streetnumber field is too long (borrowers.streetnumber is varchar(10).
Test plan:
0. Don't apply this patch
1. Create a new patron with a streetnumber longer than 10 characters
2. Save
=> The patron has not been created and the app explodes
The error is about extended_attributes and not meaningful
Can't call method "extended_attributes" on an undefined value at /kohadevbox/koha/members/memberentry.pl line 560
3. Apply the patch
4. Repeat 1. and 2
=> You get a warning on the interface and you still see the creation
form
5. Check the logs
=> The error is meaningful
"Data too long for column 'streetnumber'"
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
When a patron is added or modified and a warning appears (duplicate,
inconsistent data, etc.) the form lost the patron's attributes.
Test plan:
Create some attribute types for patrons
Create a new patron, use an userid that already exists and fill the attributes
=> You get a warning and the attributes are kept
Modify the userid and save again
Edit the same patron
Modify the attributes, as well as the userid (to get the duplicate warning)
=> You get a warning and the attributes are kept with the modified
values
Modify the userid and save again
=> The new values are saved
Edit the attributes from the detail page (so not with the full edit form)
Modify them and save
=> The new values are saved
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>
We should use Koha::DateUtils instead of Date::Time directly
This patch simplay replaces calls to now() with a call to dt_from_string()
which does effectively the same thing.
Probably reading the code and verifying changes is sufficient but...
To test:
1 - confirm the files all compile
2 - confirm all tests pass
3 - confirm Koha still works
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Librarians should be able to define what sections in member entryfields in 'Main address',
'Contact' and 'Alternate contact' in member entry form for guarantee's are pre-filled from guarantor's record
The 'Guarantor surname, 'Guarantor first name' and 'relationship' fields
in the 'Contact' section should not be filled from guarantor patron
record as those fields are intended for guarantor's without patron
records in Koha.
Test plan:
1. On an adult patron's record (which has all fields filled out in the
'Main address', 'Contact' (Except for 'Guarantor surname', 'Guarantor
first name', and 'relationship'), 'Alternate address', and 'Alternate contact') select 'Add guarantee'
2. Observe:
* Fields in 'Main address' are all automatically pre-filled
from guarantor record
* Fields in 'Contact' (except 'Guarantor surname', 'Guarantor firstname'
and 'relationship') are all automatically pre-filled from guarantor
record
* Fields in 'Alternate address' (except for Contact note) are pre-filled from guarantor record
* None of the fields in 'Alternate contact' are pre-filled from guarantor
4. Apply patch
5. Run database updates
cd installer/data/mysql
sudo koha-shell <instancename>
./updatedatabase.pl
6. Restart plack:
sudo koha-plack --restart <instancename>
7. Go to Administration > Global system preferences and search for the
new PrefillGuaranteeField system preference
8. Observe this syspref contains checkboxes and the following are
selected by default:
Contact - Primary email
Contact - Primary phone
Main address - Address
Main address - City
Main address - Country
Main address - State
Main address - ZIP/Postal code
Main address - street number
Please note: 'Contact - Guarantor surname', 'Contact - Guarantor first
name', Contact - relationship' are not in PrefillGuaranteeField syspref
as they are for non Koha patrons and so should not be pre-filled from a Koha
patron.
9. Repeat step 1 and observe the following fields are prefilled from guarantor:
In Main address section -
streetnumber
address
city
state
zipcode/postal code
country
In Contact section -
Primary phone
Primary email
10. In the PrefillGuaranteeField syspref click '[Select all]' checkboxes
11. Repeat step 1 and observe all fields in 'Main address', 'Contact'
(except Guarantor surname, Guarantor first name, and relationship),
Alternate address and Alterate contact are filled from guarantor record.
i.e. The values in guarantor's 'Alternate address' fields fill the
guarantee's 'Alternate address' fields
12. Change a few of the prefilled field values and 'Save' and observe your changes
have been saved in addition to the unaltered pre-filled values in other
fields
13. Amend PrefillGuarantee field syspref to have no checkboxes selected
14. Repeat step 1 and observe none of the fields in Main address,
Contact, Alternate address and Alternate contact are pre-filled
15. Run tests:
sudo koha-shell <instancename>
prove xt
prove t
Sponsored-by: Waitaki Distict Council, NZ
Signed-off-by: Sally <sally.healey@cheshiresharedservices.go.uk>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
1 - Verify on staff side that patron can be edited to opt in our out of auto renewal
2 - Check out some items to a patron opted in to auto renewal
3 - Ensure the items are checked out and set to autorenew
4 - Login on the opac at the patron
5 - Verify items cannot be renewed as scheduled for auto-renewal
6 - On staff side, opt patron out of auto renewal
7 - Verify on opac items are no longer marked for auto renewal
8 - Run the auto renewal cron job, items are not renewed
9 - Set 'no renewal before' to a setting that would prevent renewal
10 - Verify that opting patron in or out of auto renewal changes only the reason items cannot be renewed
11 - Set 'no renewal before' to a setting that would allow for renewal
12 - Verify that opting patron in/out changes their ability to renew
13 - Verify that when opted out cron does not renew
14 - Verify that when opted in the item is auto renewed
15 - Reset the due date, opt out, verify manual renewal succeeds
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Dealt with that previously in the module during the rebase.
It conflicted with bug 23281.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
We do no longer need this package, we can use
Koha::Patron::Attribute::Types directly instead.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
We can then now start to move methods from C4::Members::AttributeTypes
as well.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
There is already a method in Koha::Patron::Attribute to check the
uniqueness constraint, let us it to replace CheckUniqueness
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch replace Koha::Patron->get_extended_attributes with
->extended_attributes
It's now a getter a setter method.
It permits to replace UpdateBorrowerAttribute and use
create_related from DBIx::Class
Notes:
* We face the same variable names difference than in a previous patch
(value vs attribute)
Bug 20443: Remove SetBorrowerAttributes
squash + RM get_extended_attributes
RM get_extended_attributes
SQUASH Bug 20443: Remove UpdateBorrowerAttribute and SetBorrowerAttribute
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The GetBorrowerAttributes subroutine return the attributes for a given
patron.
Using get_extended_attributes we can acchieve it easily. The problematic
here is to restore the method's name (value vs attribute,
value_description vs description of the authorised value, as well as
display_checkout that should not be a method of Attribute, but
Attribute::Type instead)
value_description was used when the attribute types were attached to an
authorised value category. To avoid the necessary test in template and
controller there is now a $attribute->description method that will
display either the attribute's value OR the value of the authorised
value when needed. We should certainly use this one from few other
places.
Notes:
* This patch rename Koha::Patron->attributes with Koha::Patron->get_extended_attributes.
It will be renamed with Koha::Patron->extended_attributes in ones of the next
patches when it will become a setter as well.
* GetBorrowerAttributes did not care about the library limits, we still
do not
* The opac_only flag was not used outside of test, we drop it off.
* To maintain the existing behavior we add a default order-by clause to
the search method [code, attribute]
* From C4::Letters::_parseletter we always display the staff description
of the AV, There is now a FIXME to warn about it
* FIXMEs are not regressions, existing behaviors must be kept
* TODO add a new check to bug 21010 to search for inconsistencies in
patron's attributes attached to non-existent authorised values
* One test has been updated in Modifications.t, order_by is now
by default set to ['code', 'attribute']
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 14570 removed the guarantor pre-fill functionality when selecting
'Add guarantee' to an Adult patron. This is because guarantor
information would now only display if (1) the patron record exists
(which it won't when first adding guarantee to guarantor record) and (2)
if there is already a guarantor added to a guarantee
This patchfix will pre-fill guarantor fields and address fields (so the guarantee
has the same address as the guarantor) if no relationship (existing
guarantor data exists) and a guarantor_id is handed to memberenty.pl in
URL when clicking 'Add guarantee' button on Adults patron record.
Test plan:
1. Add adult patron make sure to fill in their 'Main address' details
2. Select 'Add guarantee'
3. Observe no details of the adult patron are displaying in the
'Guarantor information' section or 'Main address' sections of memberentry.pl
4. Select 'Search to add', search for your adult patron and choose
'Select' to add them as guarantor
5. Fill out rest of memberentry.pl and 'Save'
6. Observe adult is showing as the guarantor
7. Apply patch
8. Run tests:
sudo koha-shell <instancename>
prove xt
prove t
9. Confirm tests pass
10. Return to your adult patron
11. Select 'Add guarantee'
12. Observe in 'Guarantor information' and 'Main address' sections of
memberentry.pl are pre-filled with the 'patron #' (borrowernumber),
surname, firstname and street number, address, address2 (if you
filled that in on adults account), city
13. Fill out the rest of memberenty.pl and save and confirm your adult
patron is showing as the guarantor and the pre-filled address details
have been saved and are showing
14. Repeat steps 10,11 and 12 and in the 'Guarantor information' select
'Search to add' and add another adult as guarantor
15. Fill out the rest of memberentry.pl and 'Save' and notice with this
patch applied you can still add multiple guarantors successfully
Sponsored-by: South Taranaki District Council, NZ
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: George Veranis <gveranis@dataly.gr>
Signed-off-by: Kyle M Hall <kyle@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>
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>
Coming from
commit 51aa6db46c
Bug 12001: Move GetMemberAccountRecords to the Koha namespace
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 9978 should have fixed them all, but some were missing.
We want all the license statements part of Koha to be identical, and
using the GPLv3 statement.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds some additional handling to prevent undercollection of
fees at the server side.
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
It is the same as for debit types.
It adds a new column `archived` in table `account_credit_types` that has
the same purpose than `account_debit_types.archived`
Test plan:
0. Apply patch && run updatedatabase && update_dbix_class_files
1. Go to Admin » Credit types
2. Add a new credit type, give it a code and a description and check
'Can be manually added'
3. Go to a patron's accounting section, 'Create manual credit' tab
4. Verify that the new credit type appears
5. Return to Admin » Credit types and archive the credit type
6. Verify that the new credit type is not available anymore in 'Create
manual credit'
7. Restore the credit type and verify that it is available again
8. Create a manual credit with the new credit type
9. Go to Reports » Cash register and make sure you can find the
transaction by filtering on transaction type
10. Edit the new credit type and set some library limitations, make sure
that the credit type doesn't appear if you're connected to a library
you didn't selected, and that it appears if you're connected to a
library you selected.
Note to QA team:
The change in Koha/Account.pm, I added it because otherwise Koha died
when adding a manual credit with a custom type.
In that case, offset type will default to 'Manual Credit'. I'm not sure
if that is the best thing to do. I'm open to suggestions :)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
1. Create manual invoice for any patron and click on "Save", you should
be redirected to Account tab
2. Create manual invoice for any patron and click on "Save and pay", you
should be redirected to Account tab
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 11911 replaced the permission of suggestions.pl (create a purchase
suggestion) from catalogue => 1 to acquisition => 'suggestions_manage'.
However we have a lot of acquisition scripts that have lax permissions
(acquisition => '*' which means any sub permissions of acquisition is
enough).
That causes problem when a circulation staff can create purchase
suggestions but not access acquisition information.
One solution is to move the suggestions_manage subpermission out of the
acquisition permission and create a new suggestion permission.
Test plan:
0. Setup
* Create a patron with several permission (and full acquisition
permission)
* Create another patron with several permission, and suggestions_manage
permission
* Create another patron without the suggestions_manage permission
1. Apply the patch and execute the update database entry
2. Note that the third patron you create still does not have
suggestions_manage
3. Confirm that you can create a purchase suggestion if you have
suggestions_manage, but cannot access acquisition pages if you do not
have any subpermissions of the acquisition permission
Signed-off-by: Hayley Mapley <hayleymapley@catalyst.net.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
and remove 'scalar' keyword in calls where it's not needed.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
So far nothing is displayed if a librarian removes patron with
outstanding credits.
Note that outstanding debits blocks the deletion.
Test plan:
- Create a patron with outstanding credit
- Create a patron with outstanding debits
- Delete the 2 patrons
=> With credit - You get a warning but do not block the deletion
=> With debits - You get a warning message that blocks the deletion
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
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 patch adds a the ability to define where a debit type will be
available as a option for use.
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 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>
When a patron is created with a guarantor but a duplicate is found (or any other warnings I guess) the guarantor's info are lost.
This patch improves on previous functionality by retaining the select guarantor relationship as well.
Test Plan:
1) Create a new child with a name already used, add a guarantor
2) Attempt to save, no the guarantor is not shown when the editor is redisplayed
3) Apply this patch
4) Restart all the things!
5) Repeat 1
6) Note the guarantor is retained and the relationship is as well!
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Correct the capitalization of the class name introduced in bug 23788.
Test plan:
1) Prior to patch attempt to 'pay off selected' - Note a server error
2) Apply patch
3) Attempt to 'pay off selected' - Note it now works as expected.
4) Signoff
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
There are bugs in both master and 19.05, but different.
Anyway we should have this check to make sure a negative value will have
the same behavior: trigger the confirmation message (instead of a blank
page).
If we want to reject the deletion of a patron with credit we should
handle it on a separate bug report (behavior change)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Individual fees cannot be overpaid of over-written off, but it's possible to 'overpay' a writeoff of selected fees.
Test Plan:
1) Create 3 fees
2) Pick 2 and choose "Write off selected"
3) Write off more than the total amount of those fees
4) Apply this patch set
5) Restart all the things!
6) Try again, you should no longer be able to!
Signed-off-by: Sean McGarvey <seanm@pascolibraries.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
