To test:
1. APPLY PATACH and restart services.
2. Find the borrowerRelationship system preference. The description should no longer include the words "Leave empty to deactivate."
3. Populate the system preference with at least 1 choice.
4. Find a patron category with can_be_guarantee set to 'Yes'.
5. Quick add a patron of that type, making sure the relationship field shows in the Patron guarantor section. ( You have to +Add gaurantor before this field will show )
6. The values in the dropdown should refelct the borrowerRelationship values.
7. With BorrowerMandatoryField make relationship mandatory.
8. Try step 5 again, this time the Relationship field should be mandatory.
9. Remove the field from BorrowerMandatoryField and add it to BorrowerUnwantedField.
10. Do step 5 again, the relationship field should not show on the quick add form.
Signed-off-by: Myka Kennedy Stephens <mkstephens@fosgail.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
As Emmy stated on comment9, this line is indeed unneeded (and wrong).
A successful cud-insert/cud-save does not come here.
And it is set for add_form, edit_form and duplicate later on.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
If an error occurs while adding new patron, after fixing the error and
hitting save, patron entry page reloads to "Modify patron" section
and error "Patron not found. Return to search" is displayed. But no
patron is saved.
This happens because we declare template param op too early in the
code and it receives value "cud-insert" instead of "add_form" as it should.
To test:
1. Add new patron and cause an error (wrong age etc.).
2. Attempt to save patron, error message is displayed.
3. Fix your errors and attempt to save again.
=> Error message "Patron not found. Return to search" is displayed and new
patron is not saved to database.
4. Apply this patch.
5. Repeat steps from 1 to 3.
=> Saving patron should now work.
=> To be save, test if modifying patron also works as it should.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
hen dateexpiry is in BorrowerUnwantedField it is hidden in patron edition form.
The problem is when editing an existing patron the value is re-computed with category settings, as if it where empty.
This comes from all fields in BorrowerUnwantedField beeing removed from %newdata in memberentry.pl.
Whe must skip dateexpiry.
Test plan :
1) Be sure dateexpiry is not in BorrowerUnwantedField
2) Define a patron category with enrollment period 12 month
3) Create a new patron in this category
4) Its expiration date is in now + 12 month
5) Edit the patron category to set enrollment period 6 month
6) Add dateexpiry in BorrowerUnwantedField
7) Edit the patron and save
=> Without patch the expiration date is changed to now + 6 month
=> With patch the exporation date is unchanged
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Perl-tidied.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch remove the REST API call in select_user function and retrieve the patron's data from borrower_data
To test:
1) Apply patch
2) Search PrefillGuaranteeField preference and make sure some fields are selected
3) Select a user that can have a guarantor
4) In the edit form, click on "Search to add" in "Patron guarantor" fieldset
5) Choose a patron who has at least one of the fields in 1) set
6) Click Select
7) Confirm guarantee's information is filled from the guarantor's record
8) Check that any preexisting information is not overwritten
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This attachment correct the populate of fields by using the api mapping.
Now All fields are populated following the selected PrefillGuaranteeField options
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When creating a new guarantee from the guarantor, the preference PrefillGuaranteeField dictates some fields to be transfered from guarantor to guarantee. This patch makes it so those informations are also transfered when adding a new guarantor relationship to an existing patron.
To test:
1) Apply patch
2) Search PrefillGuaranteeField preference and make sure some fields are selected
3) Select a user that can have a guarantor
4) In the edit form, click on 'Search to add' in 'Patron guarantor' fieldset
5) Choose a patron who has at least one of the fields in 1) set
6) Click 'Select'
7) Confirm guarantee's information is filled from the guarantor's record
8) Check that any preexisting information is not overwritten
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Use of uninitialized value $op in string eq at /kohadevbox/koha/members/memberentry.pl line 86.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug 34478: TO SQUASH op modify=>edit_form, add=>add_form ( pass opadd to template )- memberentry.pl
The template expects opadd when showing the form - along the way it was changed to 'add' and broke new patron
entry
Bug 34478: TO SQUASH op modify=>edit_form, add=>add_form ( pass op to template )- memberentry.pl
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug 34478: [TO SQUASH] actionType parameter not used - memberentry.pl
syntax error at members/memberentry.pl line 103, near "\|"
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We should no longer need to check CSRF token from pl files
TODO - there is a change for some files where we returned 403
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We do not longer need to generate_csrf from pl files
TODO - members/boraccount.tt and sco/sco-main.tt needs to be adjusted
Bug 34478: [TO SQUASH] Remove generate_csrf from pl
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Add two requirements when registering a new patron:
- A child patron must have a guarantor. This is controlled by
a new syspref ChildNeedsGuarantor.
- A guarantor cannot be a guarantee.
Test plan:
1. Add a child patron without guarantor or child patron with guarantee
as guarantor succesfully.
2. Apply this patch.
3. Add a child patron as a guarantor.
=> Error is raised.
4. Turn syspref "ChildNeedsGuarantor" ON.
5. Add a child patron without a guarantor and error "Child needs a
guarantor" is raised.
6. Add guarantor. Guarantor can either be existing patron or added with
"Contact" section.
=> Save without errors.
Also prove t/db_dependent/Koha/Patron.t
Sponsored-by: Koha-Suomi Oy
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When one tries to create an account with patron guarantor and
error occurs (already used username, wrong age etc.), guarantor
information is lost. This patch always saves added patron
guarantor information to the template param new_guarantors.
To test:
1. Create a new account but cause an error that will keep the
account from saving (enter the wrong age for a category or
give the patron a username that's already being used).
2. Search for and select a guarantor.
3. Try to save the account and wait for the "The following
fields are wrong. Please fix them." message.
=> Note that the guarantor information is gone and you need
to search for and select the guarantor again.
4. Apply this patch.
5. Repeat steps 1.-3.
=> Note that guarantor information hasn't been lost.
This patch also removes code block from duplicate patron
check because we now save param new_guarantors even if
error doesn't occur.
To test:
1. Create a new account but cause a duplicate patron error.
2. Search for and select a guarantor.
3. Try to save the account.
=> Guarantor information should persist.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
The idea here is to confirm this patch does not introduce regression.
For that you will play with the CardnumberLength syspref and create a
new user, modify an existing one, and check that the UI does not let you
modify an invalid cardnumber.
The onboarding process and the patron import tool will also have to be tested
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Bug 33940: Fix selfreg
please squash with first patch
Bug 33940: Fix messages we sent to templates
please squash with the first patch
Bug 33940: Fix what we send to memberentry
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
Note: We will address this again when installing a plugin, but
first we test with the legacy userid code.
Add a new user with members/memberentry in staff.
Edit this user, change userid in staff. Try full form and partial
one.
If you remove userid or replace by a space (when mandatory), Koha
should regenerate a legacy userid.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch removes the use of GetDebarments from members/memberentry.pl
and replaces the references in the templates with patron.restrictions.
Test plan
1. Add a new user and confirm that the patron restrictions section does
not appear on the form
2. Edit the user and confirm the patron restrictions section now appears
3. Add a manual restriction using the patron edit form
4. Confirm the restriction appears on the patron edit form
5. Confirm you can remove the restriction usine the patron edit form
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1 - go to a patron detail view, click "add guarantee"
2 - Confirm form loads
3 - Confirm categories lsited are eligible to have a guarantor
4 - Fill out required fields and confirm patron saved correctly
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Rather than generate a custom hash for these fields, we should treat them as other borrower data fields
To test:
1 - Edit a patron, note the 'Lost card' and 'Gone no address' fields
2 - Edit syspref BorrowerunwantedField
3 - Set gonenoaddress and lost as unwanted
4 - Edit patron, the fields remain
5 - Apply patch
6 - Edit a patron, fields are hidden
7 - Unhide one of the fields
8 - Edit a patron and confirm it shows and saves correctly
9 - Unhide the other field
10 - Confirm it can be edited and saved
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch moves the new classes under ::Patron::Restriction:: and
enhances the Unit tests for those classes.
NOTE: We should drop keyed_on_code as part of bug 31095
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch displays a restriction type select box (when appropriate)
when adding manual patron restrictions
Sponsored-by: Loughborough University
Signed-off-by: Benjamin Veasey <B.T.Veasey@lboro.ac.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The structure of debarments has changes slightly in that the displayed
text is now a product of a call to Koha::RestrictionTypes rather than
just the debarment's code. This patch allows for that
Sponsored-by: Loughborough University
Signed-off-by: Benjamin Veasey <B.T.Veasey@lboro.ac.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The idea rely on the KohaDates TT plugin for the date formatting. We
should not have any output_pref calls in pl or pm (there are some
exceptions, for ILSDI for instance).
Also flatpickr will deal with the places where dates are inputed. We
will pass the raw SQL value (what we call 'iso' in Koha::DateUtils), and
the controller will receive the same value, no need to additional
conversion.
Note that DBIC has the capability to auto-deflate DateTime objects,
which makes things way easier. We can either pass the value we receive
from the controller, or pass a DT object to our methods.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
In which case do we pass category_type to this script? Am I missing
something?
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
== Test plan ==
1. Apply all patches
2. Create a new patron in a given category
=> Form show the dropdown with the selected category
3. Edit again
=> Value is kept
4. Edit a category to give it specific values for: messaging prefs,
password strength/length, can be guarantee
5. Edit the patron, change the category, and confirm that the different
limitation are correctly applied.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The code that populates the patron messaging preferences on initial form load
expects to have a category selected. Currently we only have one if one was
passed to the form. When creating an account from a parent, we don't have a
category explicitly selected - so we can just select the first of the possible
categories
To test:
1 - In KTD set 'Juvenile' category to have some messaging preferences
2 - Find a patron, say Edna Acosta, and 'Add guarantee'
3 - In new form preferences are blank, cancel
4 - Apply patch, restart all
5 - Go to Edna, click 'Add guarantee'
6 - Preferences are populated!
7 - Cancel
8 - Go to 'Patrons' module
9 - Click "+ New patron"
10 - Confirm messaging preferences load correctly when not adding child
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1/ Add 'Email' to the 'SMSSendDriver' system preference.
2/ Make sure 'EnhancedMessagingPreferencesOPAC' and 'EnhancedMessagingPreferences' are turned on.
3/ Add some SMS providers (/cgi-bin/koha/admin/sms_providers.pl) with different names.
4/ Notice on memberentry.pl and opac-messaging.pl the SMS providers sort by when they were added, not alphabetically.
5/ Apply patch and restart services.
6/ Look at memberentry.pl and opac-messaging.pl and notice that they SMS providers now sort alphabetically.
Signed-off-by: George Williams <george@nekls.org
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
JD Amended patch: squashed and edited commit message
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
1) Have some patron categories that can and cannot be guarantee
2) Visit a patron's account and click the "Add guarantee" button
3) In the "category" dropdown, note that all categories are available
4) Apply this patch
5) Repeat step 2 and 3; the dropdown now only contains the categories
for which "can be guarantee" is set to "Yes".
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This adds a new field "Can be guarantee" to patron categories so it
becomes possible for any category type to have a guarantor.
To test:
1) Have a patron category of type 'Adult' and one of type 'Child'
2) Confirm, by searching for the "Patron guarantor" fieldset in the
edit/create form, that:
=> a patron of the first category can't have a guarantor
=> a patron from the second category can
3) Apply patch and run updatedatabase.pl
4) Edit the categories and note the new "Can be guarantee" field
5) It should have been set to "yes" for the "Child" and to "no" for
the "Adult"
5) Repeat step 2. It should behave in the same way.
6) Edit the "Can be guarantee" for any of the category and check
that the fieldset only appears when "Can be guarantee" is set to "yes"
7) prove t/db_dependent/Patrons.t
=> tests should still pass
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1 - Sign in as a superlibrarian
2 - Find a patron account with no password expiration set
3 - View member detials
4 - note expiration says 'Never'
5 - Edit patron
6 - Set patron expiration
7- Save
8 - View details, confirm password expiration shows correctly
9 - Sign in as non-superlibrarian
10 - Confirm you don't see expirationdate on details page
11 - Edit patron and confirm password expiration does not show
12 - Edit HTML and confirm you epxiration date not saved
<input type="text" name="password_expiration_date" value="2052-05-02">
Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch replaces the AutoEmailOpacUser system preference with a new
AutoEmailNewUser preference. This makes the functionof the preference
clearer.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch updates all references to the former ACCTDETAILS notice to
use the new WELCOME email notice instead.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
The original notice was sent using SendAlerts, which triggers
immediately on submission and doesn't wait for the cron task.
This patch restores that immediacy and also fixes a bug in the imports
on the original patch.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
We actually have a Koha::Patron method to do all the work of finding the
right patron primary email address for notices.. we can use that here
instead of doing it long hand.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
The ACCTDETAILS notice apparently bypasses message_queue; notices are sent directly to the linux mail queue.
Test Plan:
1) Apply this patch
2) Create a new patron with an email address
3) Note the patron's ACCTDETAILS notice shows in the patron's messages
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
