To test:
0. APPLY PATCH, restart_all
1. Create an accountline and make note of the accountline.date
2. On that accoutnline edit the note.
3. Confirm that the accountline.date does NOT update.
Signed-off-by: Juliet Heltibridle <jheltibridle@rcplib.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 1c50f6b774)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
If the "arrow" button on the patron search is clicked with no value in
the textbox, it redirects to members/members-home.pl and performs a
search with no value automatically. It makes more send for it to behave
as the "Patrons" link in the navbar that directs to members-home.pl
where the librarian can then perform a more advanced search.
Test Plan:
1) Click the "Search patrons" link on the header, then the arrow button
2) Note an empty patron search is performed immediately
3) Apply this patch
4) Restart all the things!
5) Repeat step 1
6) Note a paton search is no longer triggered automatically
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 222e3161cc)
Signed-off-by: Chloé Zermatten <chloe.zermatten@openfifth.co.uk>
Generated using
`perl misc/devel/tidy.pl --perl`
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 849f67988f)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
To test:
1. prove t/db_dependent/Koha/Patron.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit d214d441a8)
Signed-off-by: Jacob O'Mara <jacob.omara@openfifth.co.uk>
Adding a new guarantee and storing it fails with "Creating a patron"
selected in TrackLastPatronActivityTriggers when guarantors are set
to be mandatory. The problem comes from Koha::Patron->store called
in update_lastseen. Since we validate guarantor in Koha::Patron->store
but don't store them in there, new call to store fails because it
doesn't receive guarantor info as parameter.
As a solution, we should validate guarantors in separated method.
Validation can't be moved e.g. to Koha::Patron::Relationship->store
since this could lead to situations where guarantee is stored without
guarantor. This patch adds new method validate_guarantor and adjusts
old guarantor requirements tests to match this new method.
To test:
1. Select option "Creating a patron" in "TrackLastPatronActivityTriggers" syspref.
2. Enable syspref "ChildNeedsGuarantor" and make sure you have options in
"borrowerRelationship" syspref.
3. Create a guarantee patron, fill all required fields and add guarantor for patron
(either add Patron guarantor or fill Non-patron guarantor inputs).
4. Attempt to save patron.
=> Error box is displayed with text "The following fields are wrong. Please fix them.".
=> Logs show error "Patron creation failed! - [Child patron needs a guarantor]".
5. Apply this patch.
6. Create a guarantee patron again and save.
=> Patron should be saved correctly.
7. Create a new guarantee patron but this time don't add patron guarantor or fill
non-patron guarantor inputs.
8. Attempt to save patron.
=> Save should fail with error "A child patron needs a guarantor."
9. Add patron guarantor who can also be a guarantee and save.
=> Save should fail with error "A guarantor cannot be a guarantee."
Also prove t/db_dependent/Koha/Patron.t
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Works as advertised.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 382ba17a8c)
Signed-off-by: Jacob O'Mara <jacob.omara@openfifth.co.uk>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Pamela Bird <pbird@cityofchesapeake.net>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1. Add some debit types that can be manually invoiced.
2. Go to members/maninvoice.pl?borrowernumber=X where X is your
borrowernumber
3. In the type dropdown see that the entries are sorted by code not
description.
4. APPLY patch and restart_all
5. Try again, now it should sort by code.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Merging patrons only required edit_borrowers permission
but would result in a patron deletion.
This patch requires a new merge_borrowers subpermission
To test:
1. Give a patron the following permissions
catalogue, edit_borrowers, list_borrowers
2. Log into the staff interface as the patron
3. Do a patron search and select 2 patrons
4. Click merge patron - success - a patron got deleted
5. Apply patch, updatedatabase and restart_all
6. Repeat steps 3 and 4 - you can't
7. Add the new permission for merge_borrowers
8. Repeat steps 3 and 4 - now you can
9. prove t/Koha/Auth/Patrons.t
Sponsored-by: CLAMS
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Then consider we want to edit the logged in user settings
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This enhances the two-factor authentication management interface to allow
superlibrarians to disable 2FA for other patrons when they lose access to
their authenticator device.
Controller changes (members/two_factor_auth.pl):
* Accept borrowernumber parameter to select target patron
* Implement authorization checks (self-service or superlibrarian)
* Use proper HTTP status codes (403/404) for error conditions
* Update all patron operations to use selected patron
* Integrate with new reset_2fa() method for consistency
* Pass another_user flag to template for conditional display
Template changes (two_factor_auth.tt):
* Use has_2fa_enabled() method instead of auth_method string comparison
* Prevent superlibrarians from enabling 2FA for other users
* Show explanatory message when 2FA setup is restricted
* Maintain proper conditional display logic
UI Integration changes:
* Update members toolbar to show 2FA option for superlibrarians
* Pass borrowernumber parameter in all 2FA-related URLs
* Maintain context when canceling 2FA registration
* Use consistent parameter naming (borrowernumber vs patron_id)
To test:
1. Enable TwoFactorAuthentication system preference
2. Set up 2FA for a test patron
3. As superlibrarian, visit patron details page
4. Click 'Manage two-factor authentication' in toolbar
=> SUCCESS: 2FA management page loads for the selected patron
5. Disable 2FA for the patron
=> SUCCESS: 2FA is disabled for the target patron, not the superlibrarian
6. Verify 'Enable 2FA' button is hidden with explanatory text
=> SUCCESS: Shows message that users must enable 2FA themselves
7. Test authorization: try accessing as non-superlibrarian for different patron
=> FAIL: Returns 403 Forbidden error
8. Sign off :-D
Sponsored-by: ByWater Solutions
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
1. Create several random patron circ messages with different dates. I used the following sql for my ktd:
-- INSERT INTO messages (borrowernumber, branchcode, message_type, message, message_date)
SELECT
51 AS borrowernumber,
'CPL' AS branchcode,
ELT(FLOOR(1 + (RAND() * 3)), 'L','B','E') AS message_type, -- L=Staff note, B=OPAC, E=Email (adjust to your codes)
CONCAT('Random test message ', FLOOR(RAND()*1000)) AS message,
DATE_ADD(CURDATE(), INTERVAL -FLOOR(RAND() * 1825) DAY) AS message_date -- random day in last ~5 years (5*365)
FROM (
SELECT 1 UNION ALL SELECT 2 UNION ALL SELECT 3 UNION ALL SELECT 4 UNION ALL SELECT 5
UNION ALL SELECT 6 UNION ALL SELECT 7 UNION ALL SELECT 8 UNION ALL SELECT 9 UNION ALL SELECT 10
) AS x;
2. View the patron account and notice that messages are sorted by type, but not by date.
3. Apply the patch and restart_all
4. Refresh the patron account page and clear the browser cache if necessary.
5. View the patron account again and notice that the messages are still sorted by type, but they are also sorted in descending order (newest to oldest).
6. Sign off and have a great day!
Signed-off-by: Jen Tormey <jntormey@dmpl.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
It can be useful, for instance, if a library has the same title from
different publishers (so 1 title but several biblio records) but the
user only wants a copy of the book, regardless of the publisher.
Test plan:
0. Run updatedatabase.pl and misc/devel/update_dbix_class_files.pl
1. Go to intranet search, display some results, click on some checkboxes
and click on 'Place hold' button at the top of the results.
2. Search for a patron
3. Check the 'Treat as hold group' checkbox
4. Click on 'Place hold'
5. In the next screen you should see all the holds you placed with the
additional text '(part of a hold group)' in Details column.
6. Click on the "hold group" link. A modal window should appear with
the content of the hold group (a list of holds)
7. Check in an item of one of the reserved biblios and confirm the hold
8. The hold status is changed to Waiting, and all other holds are deleted.
The other holds will also be removed from the holds queue.
9. Confirm tests pass
- t/db_dependent/Koha/Holds.t
- t/db_dependent/Reserves/HoldGroup.t
Note: the "hold group" link is displayed in the following pages:
- reserve/request.pl
- circ/circulation.pl
- members/moremember.pl
- circ/pendingreserves.pl
- circ/view_holdsqueue.pl
Note: A hold group is counted as only one hold
Sponsored-by: Catalyst IT
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When displaying messages on a patron account, group the messages by
type and label which are OPAC messages and which are internal staff
messages.
To test:
1. Find a patron and add several messages to their account, alternating
between internal staff messages and OPAC messages
--> Note that the messages display in the order that they are added and
not explicitly labeled
2. Apply patch and refresh page
--> Confirm that all staff messages display first and all OPAC messages
display underneath
--> Confirm that messages are now labeled "Staff note" or "OPAC"
3. Play around on the patron account and confirm that the message
display is consistent after taking different actions:
- On the Details page
- On the Check out page
- After adding a new staff message
- After adding a new OPAC message
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1 - Create a patron in a category that can be a guarantee and do not assign any guarantor
2 - Create a patron in a 'Child' account type and do not assign a guarantor
3 - Enable system preference 'ChildNeedsGuarantor'
4 - View 'Check out' and 'Details' tabs for both patrons, note there is no warning
5 - Apply patch
6 - Repeat 4, note warning on all pages
7 - Add a patron gaurantor on the child - repeat 4 - warning is gone
8 - Add non-patron guarantor information to other patron - repeat 4 - warning is gone
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
"One Ring to rule them all, one Ring to find them, One Ring to bring
them all and in the darkness bind them"
We've been battling against this for years, with a mixed use of
terminology and thus confusion in templates vs controllers and notice
templates. I've decided to just try and make sure all the terminology
matches throughout, and use the more popular 'tendered' term over the
'collected' term.
This patch standardizes the terminology used throughout the payment
system to consistently use 'tendered' instead of the mixed usage of
'collected' and 'tendered' that has caused confusion over the years.
Changes include:
- Update all payment form templates to use 'tendered' input names
- Update JavaScript validation and change calculation logic
- Update controller parameter handling in pos/pay.pl, pos/printreceipt.pl,
and members/paycollect.pl
- Update sample notice templates (RECEIPT) to use 'tendered' variable
- Add null check for $total_tendered to prevent perl warnings
Test plan:
1. Test Point of Sale payments with tendered amounts and change calculation
2. Test member account payments with tendered amounts
3. Test receipt generation (both print and email)
4. Verify JavaScript validation works correctly
5. Confirm no perl warnings when tendered amount is undefined
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
* on the patron page click edit at the top, entered a preferred name, and hit save
* we should see the preferred name being displayed instead of the first name for the user
* go back to the main edit page and change the preferred name to a blank space
* We should revert back to the first name being used
* if we open the edit page back up we should see the first name in the preferred name field
* Edit the preferred name again and click on details
* open up any of the sections other then contact information
* hit the save button on the section without changing anything
* you should still see the preferred name you set being used.
* open up an individual section other then contact method, change a value, then save
* you should still see the preferred name you set being used.
* open up the contact information section and save without changing anything
* the preferred name should be intact
* open up the contact information and change the preferred name, and save.
* you should see the new preferred name reflected.
* Open up the contact information section, change the preferred name field to a blank and save.
* you should see the first name being used now.
* Open up the contact information section, and put any number of spaces in the preferred name with nothing else and then save.
* you should still see the first name being used.
Signed-off-by: CJ Lynce <cj.lynce@westlakelibrary.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The first motivation of this patch is to remove the following warnings
from t/db_dependent/Auth.t:
Use of uninitialized value $anonymous_patron in string eq at /kohadevbox/koha/C4/Auth.pm line 1497
Actually a correct fix seems to add a new `is_anonymous` method to
Koha::Patron in order to remove the warnings from everywhere else.
Test plan:
Confirm that you cannot log in using the anonymous patron and that the 2
tests are passing
prove t/db_dependent/Auth.t t/db_dependent/Koha/Patron.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
If a yellow error message appears when saving the guaranteed patron,
also an extra popup message "Patron is already a guarantor for this
patron" will appear on the screen. It should only appear when you try
to add the same patron as a guarantor that already is a guarantor for
that patron. This happens because js function select_user is triggered
every time when guarantor data is send back to front-end with variable
new_guarantors if error occurs. Already existing guarantors shouldn't
be send back to front-end since their data is not lost. This patch
changes existing guarantors form elements to use classes "guarantor_id"
and "guarantor_relationship" to prevent this.
To test:
1. Find a patron with Patron guarantor or add first a Patron guarantor
(not a Non-patron guarantor) to a juvenile patron and save.
2. Edit again the same patron with guarantor and modify their age
to be greater than the upperage or under the required age of the
patron category.
=> Notice that you will get a yellow message "The following fields
are wrong. Please fix them..."
=> Notice that you will also get a pop up notice that says "Patron is
already a guarantor for this patron".
3. Apply this patch.
4. Repeat step 2.
=> Confirm that yellow message box is displayed but "Patron is..."
pop-up is not
=> Also confirm that guarantors data is not lost.
5. Try to add same patron guarantor as guarantor for guarantee patron
again.
=> Confirm that pop-up is displayed right after attempting to add
guarantor.
6. Try to add new guarantor for patron.
=> New guarantor should be added.
7. Attempt to save the patron.
=> Confirm that both guarantors data is still displayed in form.
8. Fix patrons age and attempt to save.
=> Patron is saved and both guarantors are displayed in their
details.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
We don't need to check if $op is add_form after
error, since this value always changes.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
If error occurs while creating a new patron messaging
preferences are either lost or reseted as default
fro patron category. This patch adds new method
restore_form_values to restore already added messaging
preferences.
To test:
1. Enable syspref EnhancedMessagingPreferences.
2. Create a new patron but cause an error to prevent it from
saving (e.g. add wrong age).
3. Add messaging preferences for patron (if there are default
preferences, add also new ones or remove defaults).
4. Attempt to save.
=> Note that messaging preferences were lost and you need to
readd them.
5. Apply this patch.
6. Repeat steps from 2 to 4.
=> Note that messaging preferences which you added are kept
even if error occurs.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Update the patch to use Koha::Account and it's associated 'outstanding'
methods to ensure we accurately portray outstanding amounts rather than
'all credits' totals.
I also remove the unused `$balance` variable from the
members/moremember.pl controller.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1: Have patrons with a variety of credit/debit combinations
2: Confirm Koha shows the total debit amount in patron_messages if any debits exist
3: Confirm Koha does not show anything about creditd in patron_messages if any debits exist
4: Apply patch, restart_all
5: Confirm all patrons show both debit total and credit total
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
TEST PLAN:
1 - In the intranet add fines to a client and ensure they have no checkout
2 - Set syspref useDischarge to 'Allow'
3 - On client profile click on "Discharge", see it is possible
4 - On the opac, go to the tab "Ask for discharge", see it is possible
5 - Apply patch
6 - Click on the button "Ask for discharge" -> it will not be possible
and you will be propperly messaged
7 - Return to the tab "Ask for a discharge", there will be no button
anymore
8 - On the intranet page, there will be no button anymore
9 - Check out a book
10 - Repeat 7 and 8 and see the message include issue with checkout
11 - Remove fine and repeat 7 & 8
Bug 14250: (QA follow-up) Deduplicate checks
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 14250: (follow-up) Update messages
Update the text for the reasons the patron cannot be discharged.
Bug 14250: (follow-up) Refacto the algorithm for discharge messages
TEST PLAN:
1 - In the intranet add fines to a client and ensure they have no checkout
2 - Set syspref useDischarge to 'Allow'
3 - On client profile click on "Discharge", see it is possible
4 - On the opac, go to the tab "Ask for discharge", see it is possible
5 - Apply patch
6 - Click on the button "Ask for discharge" -> it will not be possible
and you will be propperly messaged
7 - Return to the tab "Ask for a discharge", there will be no button
anymore
8 - On the intranet page, there will be no button anymore
9 - Check out a book
10 - Repeat 7 and 8 and see the message include issue with checkout
11 - Remove fine and repeat 7 & 8
Note: removing the useless has_checkout and has_debt
Bug 14250: (follow-up) Refacto discharge messages display
The script that determines if one should display messages to the user,
informing him whether they are allowed or not to ask for a discharge is
quite hard to understand.
For sake of readability, transforming the unless to an if since the
error behaviour was in the unless and the success in the else.
Changing to success behaviour in the if and failure in the else.
Bug 14250: Tidy
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch uses the new REST API endpoint to retrieve the old holds.
We can now have 2 tables, one for the current holds and one for the old
ones.
Test plan:
Have several holds with several statuses.
Notice that you see the holds in the respective tables. Test the usual sorting
filtering DT feature and confirm that everything works as expected.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1 - Remove age limits from a Child and Adult category in Administration->Patron categories. Ensure Child category can be guarantor and Adult cannot
2 - The above step is to avoid any age checks and form resubmission which removes the guarantor fields
3 - Find/create a child patron
4 - Add a guarantee from the Adult category to the child
5 - Check the DB:
SELECT * FROM borrower_relationships WHERE guarantee_id={borrowernumber of child};
6 - Note the id colum
7 - Edit the child patron to Adult category
8 - Repeat 5
9 - Note the relationship still exists and the id is incremented
10 - Oof!
11 - APPLY PATCH, restart_all
12 - Try again steps 3 - 8
13 - The relationship should not be re-added
14 - Try with more than 1 guarantor on the record, confirming all are deleted
15 - Try adding some guarantor to patron types that should be able to, they relationship should work.
16 - Try changing some patrons to categories that do allow guarantors, making sure the relationship does stay.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test, with this patchset applied:
1) From patron accounting page -> Add a manual invoice
2) Under the transaction tab click 'Cancel charge'
3) You should see a modal that gives you the option to type in a note.
4) Type something in and select submit.
5) Ensure the note shows up in the note column.
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1) Apply patch, restart_all
2) From patron accounting page -> Create manual invoice. Enter some amount and select save and pay. Press confirm.
3) In the transactions tab, for the invoice you just created, under the actions column select issue refund.
4) This should open a modal with the ability to enter a note for the refund. Type in a note and confirm.
5) Ensure the note correctly shows in the table.
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1) From patron accounting page -> Create manual credit. Put in some amount and press add credit.
2) Under the actions column, select "Void"
3) Notice no option for a note. Press cancel
4) Apply patch, restart_all
5) Press void again. This time, you should see a modal that gives you the option to type in a note.
6) Type something in and select submit.
7) Ensure the note shows up in the note column.
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1) Apply patch, restart_all
2) From patron accounting page -> Create manual credit. Put in some amount and press add credit.
3) Under the actions column, select 'Issue Payout'
4) You can now enter a note. Type something in and press confirm.
5) Ensure the note shows up in the note column.
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. APPLY PATCH and restart_all
2. Apply a manual invoice to a patron account.
3. Go to the patron record -> accounting -> transaction tab
4. Look for the 'Apply discount' button.
5. When the 'Apply discount' modal appears notcie the 'Note' field.
6. Add a note, make sure it gets applied to this accountline.
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Log non-repeatable attributes and only log changes and creations, not deletions.
When changed, attributes are first all deleted, then the relevant ones are recreated.
This patch catches all deletions, and checks against them in the creation phase, logging
only the attributes that have changed (with before/after content). This makes it impossible
to log actual deletions.
To test:
1) Ensure tests in t/db_dependent/Koha/Patron/Attribute.t passes
Sponsored-by: Gothenburg University Library
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Clemens Tubach <clemens.tubach@kit.edu>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Combining opac with pref template is wrong. This pref should
actually be renamed to something like intranetTheme(s) or so.
Replacing the obsolete prog theme in Languages.t by undef. This
achieves the same: getting all themes for that interface.
Test plan:
Add some languages for opac and intranet. Do not enable exactly
the same set.
Enable TranslateNotices.
Verify that you have all OPAC languages on memberentry and
opac-messaging. And all languages on additional contents.
Run t/db_dependent/Languages.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested with:
OPAC languages: en, nl-NL, de-DE
Staff languages: en, de-DE, fr-FR
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When editing a child while Childneedsquarantor active, trying to delete
a guarantor while saving a non-patron guarantor will prevent the user
from saving. However, if an adult has expired, some librarian would like
to remove the account and let some information in non-patron guarantor.
TEST PLAN
Before applying patch
1 - Open Lisa Charles'page, add Henry Acevedo as Guarantor, also fill
Guarantor surname and firstname
2 - Edit the page and try and remove Henry Acevedo, it won't work
however there is still one guarantor
3 - Apply patch
4 - Try and remove Henry Acevedo -> it will work
5 - add HA as a guarantor again
6 - try and remove him AND let guarantor firstname and surname empty ->
you can't
7 - Add HA and Edna Acosta as guarantor
8 - Remove HA and ler guarantor firstname and surname empty -> you can
Signed-off-by: Thibault Keromnes <thibault.keromnes@univ-paris8.fr>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch updates sidebar menu markup so that it's consistent, with a
common class (".sidebar_menu") and a unique ID. The style is tied to the
class rather than the ID, simplifying the CSS.
Note: This patch contains indentation changes so ignore whitespace when
viewing the diff.
The updated patch contains corrections to JavaScript which needed
selectors to be changed to match the new markup.
To test, apply the patch and rebuild the staff interface CSS
(https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staff_client)
Check pages which contain each modified menu:
- Circulation -> Check out to a patron
- Catalog -> View a bibliographic record
- Administration -> View system preferences
- Acquisitions -> Acquisitions home
- Cataloging -> Stock rotation -> Manage stages and manage items for a
rotation
- Cataloging -> Stage MARC records for import
- Reports -> Acquisitions statistics
- Reports -> View dictionary
- Point of sale
- E-resource management
- Preservation
- Serials
- Tools -> Patron lists
Sponsored-by: Athens County Public Libraries
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This fixes an internal server error when renewing an expired
child patron without a guarantor, when the ChildNeedsGuarantor
is set to "must have".
Test plan:
1. Create or edit a child patron:
- Don't add a guarantor.
- Set the "Expiry date" to a date in the past.
2. Set the ChildNeedsGuarantor system preference to "must have".
3. Refresh or view the patron's check out or details page, and
select the "Renew" link under the attention heading -
this generates an internal server error message.
4. Apply patch.
5. Repeat step 3, you will now get a standard error message
"This patron could not be renewed: they need a guarantor."
6. Add a guarantor for the patron.
7. Repeat step 3, and click "Renew" - the patron is now renewed.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When we attempt to add child as guarantor the error message shown is 'A guarantor cannot be a guarantee.' it doesn't make sense
To recreate:
1. Go to Patrons
2. Click 'New patron' > 'Kid'
3. Fill out surname and cardnumber
4. Under Patron guarantor, click Add guarantor
5. Search for category = Kid and choose one of the patrons
6. Choose the relationship
7. Click 'Save'
--> Error A guarantor cannot be a guarantee.
8. Apply the patch
9. repeat previous steps
10. After clicking Save
--> the error message shown is «Child patron cannot be a guarantor.»
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This commit is generated using:
% perl misc/devel/tidy.pl
*within* ktd, to get the same version of perltidy than what will be used
by our CI (currently v20230309).
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds a new field 'preferred_name' to the patron record.
On storage (creation or update) the preferred_name is set to the firstname if no
value is passed. Patron modifications will set the preferred name to the firstname if
the preferred_name field is hidden
With this patchset preferred_name will always be set - either to the firstname, or a specified value.
PatronAutoComplete/ysearch is updated to use 'preferred_name'
To test:
1 - Apply patches
2 - Update database and restart all, clear browser cache
3 - Load a patron in staff module
4 - Confirm you see and can add a preferred name
5 - Confirm the preferred name and first name now displays on patron details
6 - Remove first name from patron record and confirm it no longer shows
7 - Edit sysprefs BorrowerMandatoryFields and BorrowerUnwantedFields to confirm you can make
new field required or hidden
8 - Sign in as patron to opac
9 - Confirm preferred name shows
10 - Edit account on opac and confirm field is present
11 - Verify DefaultPatronSearchFields contains 'preferredname' if your pref had firstname
12 - Perform checkout and patron search using preferred_name, confirm patron is found
13 - Enable PatronAutoComplete system preference
14 - Type patron's surname into Checkout or patron search but don't hit enter
15 - Confirm patron is displayed with 'preferred_name' in the preview
16 - Set 'preferred_name' in all 'Unwanted' preferences
17 - Confirm editing a patron in staff interface sets both fields when firstname updated
18 - Confirm a patron modification sets both fields when firstname updated
19 - Create a patron / perform self registration and confirm both fields set when preferred_name is hidden
20 - Remove preferred_name from Unwanted prefs and confirm preferred_name is set to firstname if nothing passed
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan:
Add a return; in AddFile to simulate a failing db insert.
Verify that an alert pops up.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.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: Katrin Fischer <katrin.fischer@bsz-bw.de>
Lucas Gass
Kyle M Hall
Jonathan Druart
Lari Taskula
Emmi Takkinen
Matt Blenkinsop
Brendan Lawlor
Martin Renvoize
Tomas Cohen Arazi
Laura_Escamilla
Aleisha Amohia
Emily Lamancusa
Nick Clemens
Imani Thomas
Andrew Fuerste Henry
Baptiste Wojtkowski
Sam Lau
Stefan Berndtsson
Marcel de Rooy
Owen Leonard
Hammat Wele
Koha Development Team