Since bug 36085, the protected flag in a patron account was removed from
the patron creation form, regardless of if the user is a superlibrarian.
- Hoist $logged_in_user lookup before the edit_form block
- Move superlibrarian capability checks after the block so they apply
to all operations including patron creation
To test:
1. Sign in as a superlibrarian
2. Go to Patrons > New patron > choose any category
3. Without this patch: the "Protected" yes/no field is missing
from the "Library management" section
4. Apply this patch
5. Repeat step 2
- The "Protected" yes/no field is now visible
6. Create the patron with Protected set to "Yes"
7. Confirm the patron is saved as protected
8. Sign in as a non-superlibrarian with edit_borrowers permission
9. Repeat step 2
- The "Protected" field should still be hidden
10. Edit an existing patron as superlibrarian
- The "Protected" field is visible and functional
11. Edit an existing patron as non-superlibrarian
- The "Protected" field is hidden
12. Sign off
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Correct genuine spelling errors identified by the codespell 2.4.x
full scan after the KTD container OS upgrade. Changes are in
comments, POD, strings, and template text across 55 files.
"SAN Ouest Provence" (the French library co-operative and Koha
sponsor) is preserved as a proper noun. Perl copyright lines
receive an inline # codespell:ignore annotation; about.tt files
(contributor attribution pages) are added to the Koha::Devel::Files
codespell exception list so that future uses of "Provence" as a
typo for "Province" are still caught in all other files.
Notable user-visible fixes:
- "submiting" -> "submitting" in authority and bibliographic merge screens
- "deleteable" -> "deletable" in patron exception messages
- "Acquistions" -> "Acquisitions" in reports dictionary
Test plan:
1. Apply patches
2. In the staff interface, go to Cataloguing > Merge records and
confirm the submit button reads "Submitting" (not "Submiting")
3. In the staff interface, go to Authorities > Merge and confirm
the same correction
4. Attempt to delete a patron with outstanding issues and confirm
the error message reads "deletable" (not "deleteable")
5. prove xt/author/codespell.t
=> All tests pass
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This patch makes it so the values copied come from the merge results
which fixes the case of copying empty values or - accurately.
To test:
1. Have a patron with some empty fields and some fields with '-'
2. Follow the original test plan and try to copy those fields
3. confirm empty fields and '-' now copy as expected
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch migrates the 'slip' printing for the ACCOUNTS_SUMMARY slip to
circ/printslip as this is a slip rather than a notice.
Sponsored-by: Open Fifth <https://openfifth.co.uk>
Signed-off-by: Marion Durand <marion.durand@biblibre.com>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch applies the new style preferences to the preview display and
email sending code.
Sponsored-by: Open Fifth <https://openfifth.co.uk>
Signed-off-by: Marion Durand <marion.durand@biblibre.com>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Replace the raw-DBI permission write block (~62 lines) with a call to
$patron->set_permissions(\%granted). Logging and the superlibrarian
guard are now handled inside the object method.
The CGI layer now only parses the flag params into a granted hashref
and delegates — keeping the controller thin and the logic testable.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Changes to patron permissions via member-flags.pl are logged as MEMBERS/MODIFY,
indistinguishable from regular patron field edits. This patch wraps the
before/after permission hashes under a 'permissions' key so that the diff
renderer displays changes as 'permissions.cataloguing' etc., making it clear
the diff relates to permissions rather than first-level patron fields.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Subroutines in members/member-flags.pl are combined and moved to Koha::Patron
Removed the html-based english description of each permission from the logging
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Changes to permissions are not logged in the Koha action_logs, making it impossible to trace changes to staff permissions. This patch ensures that all changes to permissions are logged.
Test plan:
1. Go to a staff interface
2. Search for a patron and change their permissions (note their borrowernumber)
3. Go to tools/Log viewer
4. Filter by Module = Patrons, Object = <borrowernumber>.
5. Click on submit
==> No permission changes are logged.
6. Apply the patch
7. Repeat step 1, 2, 3, 4, 5
==> Permission changes are now logged
8. Check that the diff column contains the change:
select diff from action_logs where object= <borrowernumber> order by action_id desc limit 1;
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
This patch adds a new PatronAgeRestriction, which acts in the same way
PatronSelfRegistrationAgeRestriction (a restriction on the maximum age
of a borrower), except for the intranet. It will also act as the
maximum age restrictor on the OPAC, in the event that the
PatronSelfRegistrationAgeRestriction is not set.
To test:
== APPLY PATCH ==
a) updatedatabase
b) Set the PatronAgeRestriction syspref to 20, set the
PatronSelfRegistrationAgeRestriction to 30
c) On the OPAC, try to create or modify a patron whose age is 35 years
*) Note the error message presented, suggesting the age exceeds the
maximum
d) On the OPAC, try to create or modify a patron whose age is 25 years
*) Note the submission succeeds
e) On the staff client, try to create or modify a patron whose age is
25 years *) Note the error message presented, suggesting the age
exceeds the maximum
f) Set the PatronSelfRegistrationAgeRestriction to empty
g) On the OPAC, try to create or modify a patron whose age is 25 years
*) Note the error message presented, suggesting the age exceeds
the maximum
h) On the OPAC, try to create or modify a patron whose age is 19 years
*) Note the submission succeeds
i) Set the PatronAgeRestriction to empty
j) On the staff client, try to create or modify a patron whose age is
75 years
*) Note the submission succeeds
k) On the OPAC, try to create or modify a patron whose age is 75 years
*) Note the submission succeeds
== SIGN OFF ==
Sponsored-by: Cheshire West and Chester Council
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
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>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
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>
Adds a read-only "Consents" section to the staff patron detail page
showing the patron's consent status for GDPR (when PrivacyPolicyConsent
is enabled) and any plugin-defined consent types.
Each consent displays with visual status indicators:
- Green checkmark with timestamp when consent was given
- Red X with timestamp when consent was refused
- Gray "Not specified" when no consent recorded
Test plan:
1. Enable PrivacyPolicyConsent system preference
2. As patron in OPAC: give/refuse consent at "Your consents"
3. As staff: view patron detail page
4. Verify "Consents" section shows correct status and timestamp
5. Test with no consent recorded (should show "Not specified")
6. If available, test with plugin-defined consent types
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>
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>
This makes it reusable, documentable, and testable.
This is changing code without adding a new feature or fixing a bug.
The first test plan should be to just make sure that the existing functionality is kept intact, i.e. rendering and saving the patron attribute types in the form.
As to why we need this, we're maintaining the ILL Actions plugin where we have a feature to quickly add a patron. This is designed to be as minimal as possible, but if there are any mandatory patron attribute types, those need to be considered.
To test this:
1) Apply patches and enable ILLModule syspref.
2) Install the plugin:
https://github.com/openfifth/koha-plugin-ill-actions/releases/tag/v2.4.0
3) Add a mandatory patron attribute type, you can edit the existing one in k-t-d, visit:
<staff_url>/cgi-bin/koha/admin/patron-attr-types.pl?op=edit_attribute_type&code=SHOW_BCODE
5) Tick the 'Staff interface mandatory' checkbox
6) Create a new ILL request, visit:
<staff_url>/cgi-bin/koha/ill/ill-requests.pl?method=create&backend=Standard
7) Notice there's a '+Add new user' link next to the cardnumber input at the bottom of the form. Click that.
8) Notice there's a 'Additional attributes and identifiers' section. This is only possible (without writing it again) because of the patches here.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch comprehensively updates the API keys management interface
to use the new revoke() and activate() methods with proper exception
handling.
Controller changes (members/apikeys.pl):
- Add Try::Tiny and Scalar::Util imports for exception handling
- Replace direct field manipulation (active(0)/active(1)) with proper
method calls (revoke()/activate()) to ensure logging
- Wrap method calls in try/catch blocks to handle specific exceptions:
* Koha::Exceptions::ApiKey::AlreadyRevoked
* Koha::Exceptions::ApiKey::AlreadyActive
- Implement standard Koha messages pattern with @messages array
- Improve code structure with elsif chain instead of multiple if statements
- Add proper error handling for key_not_found cases
- Include error_string for unhandled exceptions to aid debugging
Template changes (koha-tmpl/.../apikeys.tt):
- Add comprehensive error message handling for all exception types:
* already_revoked: Clear message for revoked keys
* already_active: Clear message for active keys
* key_not_found: Message for missing keys
* unhandled_exception: Generic message with detailed error string
Key benefits:
- All API key state changes are now properly logged when ApiKeyLog is enabled
- Better user experience with specific, actionable error messages
- Robust exception handling prevents crashes and provides debugging info
- Improved code maintainability and extensibility
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
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>
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>
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>
Paul Derscheid
Martin Renvoize
Brendan Lawlor
Martin Renvoize
Kyle M Hall
Hammat Wele
Jake Deery
Lucas Gass
Jonathan Druart
Pedro Amorim
Tomás Cohen Arazi
Lari Taskula
Emmi Takkinen
Matt Blenkinsop
Laura_Escamilla
Aleisha Amohia
Emily Lamancusa
Nick Clemens
Imani Thomas
Andrew Fuerste Henry
Baptiste Wojtkowski
Sam Lau