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>
Test Plan:
1) Enable reciept popups for payments and writeoffs
2) Test the "Write off" button, no popup
3) Apply this patch
4) Restart all the things!
5) Test again, you should get the popup!
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Sean McGarvey <seanm@pascolibraries.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The tab will show when the staff user has edit_borrowers
permission, but the page itself will not be accessible.
This patch fixes the page permissions to allow access
with the edit_borrowers permission as suggested by the
comments on the original bug report.
To test:
- Create a staff user with only "edit_borrowers" permission
from the borrowers module
- Try to access the holds history tab from any patron account
- Verify you are blocked
- Apply patch
- Try again and verify the page is accessible now
- Repeat with superlibrarian and full borrowers permission.
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This adds a "Claims returned" feature that extends and enhances the claims returned lost status.
To use this feature, a new LOST status to represent an item claimed as returned needs to be created.
The value of this LOST authorised value should be set in the new syspref ClaimReturnedLostValue.
Setting this system preference turns on the feature.
Once the feature is enabled, you should be able to mark checked out items as return claims from the
checkout and patron details pages, and also modify them from the new claims tab on those pages.
Returning a claimed item will notify the librarian that the item in question has a claim on it.
Setting the ClaimReturnedWarningThreshold will add an alert to make librarians aware that this
patron has many return claims on the patron's record.
Test Plan:
1) Create a "Claims Returned" lost value
2) Create some RETURN_CLAIM_RESOLUTION authorized values
3) Set ClaimReturnedLostValue
4) Set ClaimReturnedChargeFee
5) Set ClaimReturnedWarningThreshold
6) Create some checkouts
7) Claim some returns
8) Verify ClaimReturnedChargeFee works with all 3 options
9) Verify ClaimReturnedWarningThreshold shows a warning once the threshold has been exceeded
10) Edit notes on a claim
11) Resolve a claim
12) Delete a claim
Sponsored-by: North Central Regional Library System
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Lisette Scheer <lisetteslatah@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The main point of this patch is to make it possible to integrate Koha
with the Norwegian national patron database (NNPDB). Code for this was
earlier introduced in Bug 11401 and removed again in Bug 21068.
To test this is mainly a question of spotting regressions, it should
still be possible to set and change a password in all possible ways:
- Setting a password for a new user
- Changing a password in the staff client
- Changing a password in the OPAC
If these work as expected, everything should be OK.
A nice side effect of this work is that it will allow for plugins that
validate passwords. I have created a tiny plugin that enforces PIN
codes of 4 digits. (Yeah, I know, those are the worst passwords, but
some libraries do require them.) It is published here:
https://github.com/Libriotech/koha-plugin-pin
To test this way, install the plugin and try to change the password
of an exsisting user to something that is not a 4 digit PIN. You
should get an error that says "The password was rejected by a plugin".
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Updated 2019-10-23:
- Moved the plugin checks to before the call to $self->SUPER::store to
make sure patrons are not saved if the password fails a plugin check
- Made the plugin checks in set_password respect skip_validation while
retaining the functionality for NNPDB
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan
Ensure the manual credit page continues to work as it did before this
patchset.
Signed-off-by: Kyle Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
* Update C4::Accounts::chargelostitem
* Update C4::Accounts::manualinvoice
* Update C4::Circulation::_FixOverduesOnReturn
* Update C4::Circulation::_FixAccountForLostAndReturned
* Update C4::Overdues::UpdateFine
* Update C4::Overdues::GetFine
* Update C4::Overdues::GetOverduesForBranch
* Update Koha::Account->pay
* Update Koha::Account->add_debit
* Update Koha::Account->non_issues_charges
* Update Koha::Account::Line->apply
* Update Koha::Account::Line->adjust
* Update controller scripts
* Update reports scripts
* Update tests
Test Plan
1) Run the test suit and ensure everything still passes
2) Test reports/cash_register_stats still works
3) Test that adding manual invoices still works
4) Test that making payments still works
5) Test that lost item fee handling still works
6) Test that invoice printing still works
7) Test that the sco still works
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
1) Naviage to a patron record and select the accounts > manual invoice
tab
2) Add some manual invoices and confirm they are working as expected
3) Signoff
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Whenever a fine (accountlines in DB) has a precision longer than two floating points, it becomes very hard for a user to clear it.
Ex: 1.035 will be displayed as 1.04 or 1.03 depending on the screen. But entering any of those value in Pay Fine will not clear it.
The user has no way to know the exact value to enter.
This fix makes sure that the intent of the user is met, by matching the EXACT needed sum when the difference is less than 0.01.
TEST
1) Create a 1.035 fine
- Go to a Patron screen
- Fines tab on the left
- Create manual invoice
2) go to Pay fines, click Pay amount on bottom left.
3) It will show 1.03 as Total, and as Collect from patron. Click confirm.
4) An error message will appear.
5) Apply patch, do again.
Signed-off-by: Hayley Mapley <hayleymapley@catalyst.net.nz>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Just a find and replace on the changed system preference name.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
- Rename CircAutocompl system preference to PatronAutocompletion
- Take this system preference into consideration for patron search
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
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>
When fixing Bug 23589 Theodoros Theodoropoulos noticed that we are sending
headers and html after pdf output to browser.
Using exit inside eval block doesn't stop plack from generating
headers and html page after exit since CGI::Compile will catch
exit but doesn't stop emiting output. Example is:
eval {
warn "in eval";
exit;
};
warn "after eval";
Under CGI, this would print just "in eval", but under plack we get both lines
and thus generate additional header and html after we already sent pdf data.
Signed-off-by: Theodoros Theodoropoulos <theod@lib.auth.gr>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This follow-up catches the case where no cash registers have been
defined for the current branch and as such payments cannot be processed.
Test plan:
1) Ensure you have 'UseCashRegisters' set to 'Do'
2) Attempt to make a payment for a fee whilst logged into a branch that
has not yet had cash registers configured.
3) Note that you are shown a warning and cannot proceed.
4) Signoff
Sponsored-by: PTFS Europe
Sponsored-by: Cheshire Libraries Shared Services
Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch ties in the cash registers system to the paycollect payment
pages in the staff client.
Test plan:
1) Add some manual fees to a test patron
2) Select some fees to pay off
3) Note the addition of a select box for selecting your cash register
upon payment.
4) Set a branch default cash register for the current branch
5) Repeat step 3 and note that the pre-selected cash register is the one
set in step 4.
6) Unset the branch default cash register for the current branch
7) Repeat step 3 and note that there is no cash register pre-selected
8) Set 'UseCashRegisters' to 'Do not'
9) Repeat step 3 and note that there is no longer an option to select a
cash register
10) Signoff
Sponsored-by: PTFS Europe
Sponsored-by: Cheshire Libraries Shared Services
Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch just removes an unused parameter.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds the ability to set an unlimited number of guarantors
for a given patron. As before, each guarantor may be linked to another
Koha patron, and all the behavior that applies to a given guarantor
remains the same.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Find some patrons with guarantors, verify the still have their guarantor
4) Test adding and removing guarantors on a patron record, both Koha users and not
5) Verify the "Add child" button works
6) Verify NoIssuesChargeGuarantees still works
7) Verify tools/cleanborrowers.pl will not delete a guarantor
8) Verify the guarantors are displayed on moremember.pl
9) Verify the guarantor is removed by members/update-child.pl
10) Verify the guarantor is removed by misc/cronjobs/j2a.pl
11) Verify import patrons converts guarantor_id, relationship, contactfirstname,
and contactsurname into a guarantor
12) prove t/Patron.t
13) prove t/db_dependent/Circulation.t
14) prove t/db_dependent/Circulation/NoIssuesChargeGuarantees.t
15) prove t/db_dependent/Items.t
16) prove t/db_dependent/Koha/Patrons.t
17) prove t/db_dependent/Members.t
18) prove t/db_dependent/Patron/Relationships.t
Signed-off-by: Kim Peine <kmpeine@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
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>
Currently deleting a patron deletes all their holds and leaves
no record to the "old_reserves" table.
Steps to reproduce:
- Create a patron
- Add holds for patron
- Holds are recorded to "reserves" table
- Delete patron
- Confirm delete
=>Patron and all holds are deleted and no record of holds is
left in "old_reserves" table
This patch displays alert text notifying user that deleting patron
cancels all their holds. Holds are cancelled instead of deleting them.
This patch also writes stringified datetime to holds cancel log instead
of whole datetime object.
To test:
- Apply this patch
- Create a patron
- Add holds for patron
- Holds are recorded to "reserves" table
- Delete patron
- Alert text of holds is displayed
- Confirm patron delete
=> Patron is deleted, their holds are cancelled and moved to
"old_reserves" table
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nadine Pierre <nadine.pierre@inLibro.com>
Signed-off-by: Arthur Bousquet <arthur.bousquet@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
TEST
- Use a patron who hasn't checked out items before
- Set StatisticsFields to itype|ccode
- Check out some items without location
- Verify that statistics stable shows the correct number of checkouts
- Check out one item with a location or just change one of your checked out items
- Verify the total is still correct
- Change StatisticsFields to location|itype|ccode
- Verify the total has changed now - it's only 1 (the one with a location)
Apply the patch and try again
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
1/ set uppercasesurname to 'Do'
2/ register a new patron using the REST API with lowercase surname
3/ verify the surname is not saved in uppercase
4/ apply patch
5/ repeat 2
6/ verify the surname now is saved to uppercase
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch is a minor refactoring, that reuses the $account object we
already get from $patron, instead of creating new ones all over the
place. Code gets simpler to read too.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch makes paycollect store the branchcode of the current library
when payments are done.
- Try all the possible options, specially selecting things to pay for (not
using the individual buttons).
- Check on the DB, that the accountlines for the patron you're playin
with have the branchcode stored correctly in all cases:
$ sudo koha-mysql kohadev
> SELECT * FROM accountlines WHERE borrowernumber=<the_bn>;
=> SUCCESS: Things are as expected
- SIgn off :-D
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Changed the method introduced into Koha::Patron from is_category_valid
to the more specific is_valid_age to clarify it's intent to future
developers.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds a warning if a patron's age is out of limits if an assigned category.
It also adds a button allowing to change the category.
Test plan:
1) Apply patch
2) Create a patron and assign him a category having age limits set
3) Change patron's age to be older/younger than category's limits
4) At "Check out" and "Details" tabs you should see a warning with a
button allowing to change the category, eg.:
- http://prntscr.com/cz7ch3
- http://prntscr.com/cz7em4
- http://prntscr.com/cz7dj1
5) Set a valid category according to patron's age
6) Warning should disappear
7) Perform similar test again, but instead of changing the age change
the limits of a category
8) During tests verify "Change category" button everytime opens "Modify
patron" page:
http://prntscr.com/cz7g5q
9) Ensure that left-side panel is always on its expected place
10) Remove patron's date of birth and test that all categories are
allowed now
11) Run automated tests: prove t/db_dependent/Koha/Patron.t
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
In members/memberentry.pl we have to explicitely remove the template's
params that are not patron's attributes.
Certainly caused by
commit 1bb6cec902
Bug 20287: Fix update of patrons, clean the data before ->store
Test plan:
Create a restriction for a patron
Edit patron's details
Remove the restriction
=> Without this patch you get "No property remove_debarment for
Koha::Patron"
=> With this patch applied the restriction is removed
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
When creating a new patron by duplicating another, all of the patron
attributes are also copied into the form. Some of those value may be
unique, so don't copy those.
1) Create patron attribute types, one with "unique identifier", one without.
2) Create or a patron so it has values in both of those attributes.
3) Duplicate the patron
4) The edit form should retain the values from the "original" patron.
5) Apply patch.
6) Duplicate the patron - this time the attributes with unique values
are cleared.
Signed-off-by: Pasi Kallinen <pasi.kallinen@koha-suomi.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Just what the title says :)
Specifically: moremember.pl
Test plan:
Check if you see the locked message on the patron form for an account
that has been locked. (Either login_attempts<0 or >FailedLoginAttempts)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jose-Mario Monteiro-Santos <jose-mario.monteiro-santos@inLibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Just as bug 22761 moves the "Fee receipt" to the ACCOUNT_CREDIT slip, we need to move the "INVOICE" to an ACCOUNT_DEBIT slip.
Test Plan:
1) Apply this patch set
2) Restart all the things
3) Use the "print" button beside a *fee*
4) You should not see any difference from before the patches were applied
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test plan
1) Try to create patron with same name/datefobirth to trigger the
duplicate patron check
2) Click on "View existing record" link on "Duplicate patron record?"
alert message
3) You should see the patron data, but withou toolbar, menu, and so on.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch:
- removes unused templates
- use objects as much as possible
- remove many template params
Test plan:
1) Apply the patch
2) Play with patron detail page and try to broke it anyhow ;)
- messaging preferences
- enhanced attributes
- guarantors and guarantees
- fines
- messages
- checkouts
- overdues
- use different date formats, price formats and address formats
- ... there is many thinks you could try with this one page ;)
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
To test:
* Make sure AutoEmailOpacUser is set to "send"
* Create a new patron with a username and password, and an email address
* In Kohadevbox, check the mail (usually you can type "mail" and go down
to the last message) - these do not go into the message queue and they
are processed immediately.
notice that the email does not have
<<borrowers.title>> <<borrowers.firstname>> <<borrowers.surname>>
Apply this patch, restart the things, retest as above.
Signed-off-by: Hayley Mapley <hayleymapley@catalyst.net.nz>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch moves retrieval of the item type description from the script
to the template using the ItemTypes template plugin.
To test, apply the patch and locate an item which is checked out to
someone. Modify the database record for that item to remove the item
type (items.itype).
View the print summary for the patron who has that item checked out. The
page should display correctly. Checked-out items which have an item type
should show that item type description correctly.
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch adds the 'interface' field to the accountlines table and
updates all Koha::Object routines and calls to use it.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.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>
Following feedback from Josef via IRC, removing redundant code
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch moves the display of a patron's ILL requests to be inline in
the Patron Profile page, as per all other patron information.
It includes a substantial refactor of
koha-tmpl/intranet-tmpl/prog/en/modules/ill/ill-requests.tt in that it
moves the display of the illlist table (which is populated by an API
request) into it's own separate include file. It also moves the
datatable related Javascript for this table into it's own JS file. Doing
this allows us to reuse both in both the new members/ill-requests.tt
template and the pre-existing ill/ill-requests.tt template.
To test:
1) Ensure ILL is enabled and your user has sufficient permissions
2) Ensure your user has some ILL requests
3) Navigate to the user's patron profile page
4) Click on the "Interlibrary loans" tab
5) Observe that the requests table is displayed inline
6) Observe that only your user's requests are displayed
Signed-off-by: Niamh.Walker-Headon@it-tallaght.ie
This is essentially a reimplementation of attachment 84796 to take into
account all changes that had happened beneath this bug and also to
ensure JS strings are translatable.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
To test:
Attempt to create a manual fine from the patron accounting page, it
should fail.
Apply this patch, restart the things
Attempt to create a manual fine from the patron accounting page, it
should succeed.
Signed-off-by: Hayley Mapley <hayleymapley@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test plan:
1) Play with fines, should work OK
2) Try to print receipts on fines - prinfeercpt.pl, printinvoice.pl
3) git grep getnextacctno -> no occurences
4) git grep accountno should return only:
installer/data/mysql/atomicupdate/bug_21683_remove_column_accountno.perl
installer/data/mysql/update22to30.pl
misc/release_notes/release_notes_3_10_0.txt
misc/release_notes/release_notes_3_22_0.txt
5) prove
t/db_dependent/Accounts.t
t/db_dependent/ILSDI_Services.t
t/db_dependent/Stats.t
t/db_dependent/Koha/Account.t
Rescued-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
It would be change behaviour, libraries are often using POS printers and
wider table could make a problem for them and break theirs workflow.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This is not needed
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The patron summary print lists the replacement prices
and rental charges of items and totals them. With this
patch they will be formatted according to the
CurrencyFormat system preference.
To test:
- Find or create a patron with some checkouts
- Make sure some items have replacement price set
and some have a rental charge
- "Print summary" from the account in staff
- Verify that charges and prices in the checkouts
table are formatted correctly
- Toggle CurrencyFormat to different settings
Signed-off-by: helene hickey <hickeyhe@wgc.school.nz>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch makes memberentry.pl check if password needs to be updated
before attempting to call set_password. Above this there's a check that
won't raise any errors if no password is passed, or the default string (****) is received.
So we could reach that line of code with no password, but the code
wouldn't check that.
To test:
- In master, edit any patron without changing the password
=> FAIL: It raises an exception
- Apply this patch
- Edit the patron withtout changing the password
=> SUCCESS: Edit successful
- Edit the patron, changing the password
- Try to login with the new password
=> SUCCESS: The password got changed correctly
- Sigh off :-D
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>
This patch move the check for "is_expired" to the template and removes
unnecessary code from the script.
The page now correctly handles messages for patrons who are about to
expire, as defined in the NotifyBorrowerDeparture preference.
To test, apply the patch and locate a patron record which is expired.
- On the patron detail page (members/moremember.pl) you should see a
message at the top of the page.
- In the body of the page, next to the expiration date information, you
should see similar message and links.
Select a patron who will expire within the period defined in
NotifyBorrowerDeparture.
- On the patron detail page you should see a message at the top of the page.
- In the body of the page, next to the expiration date information, you
should see similar message and links.
Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch modifies the patron detail template in the staff client so
that when a patron's registration is expired a message shows at the top
of the page along with the same "Renew" and "Edit" links which appear on
the checkout page. Links are also shown next the the expiration date in
the body of the page.
This patch also corrects the capitalization of the "Edit Details" link
on circulation.tt.
To test, apply the patch and locate a patron record which is expired.
- On the patron detail page (members/moremember.pl) you should see a
message at the top of the page.
- In the body of the page, next to the expiration date information, you
should see similar message and links.
- On the patron's checkout page the "Edit details" link in the
expiration message should have correct capitalization.
Signed-off-by: Devinim <kohadevinim@devinim.com.tr>
Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
On creating manual credits, the (newly introduced) branchcode should be
set now. This trivial patch makes it work.
To test:
- Create a manual credit for a known patron
- Using MySQL check the result:
$ sudo mysql
> SELECT * FROM accountlines WHERE borrowernumber=<known_id>;
=> FAIL: The created accountline row has NULL for the branchcode
- Apply this patch
- Create a manual credit for the patron
- Run:
> SELECT * FROM accountlines WHERE borrowernumber=<known_id>;
=> SUCCESS: branchcode is set correctly
-Sign off :-D
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>
