Commit graph

101 commits

Author SHA1 Message Date
Agustin Moyano
f5373b7a5e Bug 27148: Fix bug on self registration when user category is hidden
This patch fixes the bug when there is no patron category available for
selection in self registration form. It uses PatronSelfRegistrationDefaultCategory
to get patron's password length and strength.

To test:
1. Do not apply this patch
2. Allow SeflRegistration, set PatronSelfRegistrationDefaultCategory to
   a valid patron category and finally add categorycode to PatronSelfRegistrationBorrowerUnwantedField
3. Go to opac and enter self registration form
CHECK => There is no patron category available for selection
      => Password's info alert shows "Password must contain at least
undefined characters"
4. Fill the form setting a password and send.
CHECH => You get an exception saying "You must provide a patron's
category to validate password's strength and length"
5. Apply this patch and restart_all
6. repeat steps 3 and 4
SUCCESS => Password's info alert message shows a number instead of
"undefined"
        => Password's strength and length checks are working
        => If you change default category's lenght or strength parameter it get's reflected when you refresh the page
        => When you click send, patron is saved

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-12-26 17:58:33 +01:00
Julian Maurice
96cc447045 Bug 25898: Prohibit indirect object notation
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-10-15 12:56:30 +02:00
Agustin Moyano
5848da810e Bug 23816: Add minimum password length and require strong password overrides by category
This patch adds the capability to override minPasswordLenth and RequireStrongPassword settings by category

To test:
1. koha-shell kohadev
2. koha-mysql kohadev

3. drop database koha_kohadev;
4. create database koha_kohadev;

5. go to admin page and start webinstaller. There continue the steps until onboarding.
6. reach step 3 of onboarding and create a new administrator patron
CHECH => Password control woks as normal (Minimum length 3 and strong required)

7. finish Koha installation and enter admin with your new administrator
8. set minPasswordLength to 3 and RequireStrongPassword to “Don’t require”
9. Create a new category (CAT2 from now on.. CAT1 is the category you made in onboarding process) and set minimum password length to 8 and require strong password
10. Create two new patrons, one with CAT1(patron1) and one with CAT2 (patron2)
CHECK => In both cases, try different combinations of length and strength. For patron1 the only requirement is to have 3 letters, but for patron2 the minimum length will be 8 and will require strong password.
CHECK => Try changing patron category before saving. Password requirements will change with category change.

11. Edit CAT1 and set minimum password length to 5
12. Go to patron1 details page, and change password.
CHECH => Now password minimum length is 5, but still it doesn’t require strong password

13. Edit CAT1, leave blank minimum password length and set require strong password to yes.
14. Go to patron1 details page, and change password.
CHECH => Password minimum length is back to 3, but now strong password is required

15. Set minimum password length in CAT2 to 12.
16. Go to patron2 details page, and click to fill a random generated password
CHECK => generated password should be 12 characters length

17. Set PatronSelfRegistration to Allow in admin settings
18. Go to OPAC and fill self registration from.
CHECK => Play with patron category. For each change in category, password requirements are modified.
CHECK => Set CAT1 as patron category, set ‘aA1’ as password (or another valid password for CAT1) and before hitting submit button, change to CAT2. Form should enter invalid state, and CAT2 password requirements should be displayed as error in password input.

19. Create a patron for CAT1 and another for CAT2, leaving password blank
CHECK => For CAT1’s patron, generated password length is 8 (minimum length for generated passwords), but for CAT2’s patron should be 12

20. In admin set PatronSelfRegistrationVerifyByEmail to require
21. Fill self registration form again with CAT2 as category
CHECK => Password requirements works as previous case.
22. Leave password blank and click submit

23. select * from message_queue;
24. Copy the link in the message and paste it in OPAC
CHECH => Generated password is 12 characters long. (Copy user id for next steps)

25. In admin set OpacResetPassword to Allow
26. Go back to OPAC, reload and click on “Forgot password?” link
27. Paste user id and click submit
28. Repeat steps 23 and 24
CHECK => Info message says “Your password must contain at least 12 characters, including UPPERCASE, lowercase and numbers.”
CHECK => enter an invalid password and you’ll get the same message in warning.

29. Login OPAC with the last user and your newly created password
30. Go to “Change your password” option
CHECK => Info message says “Your password must contain at least 12 characters, including UPPERCASE, lowercase and numbers.”
CHECK => enter an invalid password and you’ll get the same message in below “New password” input.

31. prove t/db_dependent/AuthUtils.t t/db_dependent/Koha/Patron/Category.t

32. Sign off

Sponsored-by: Northeast Kansas Library - NEKLS

Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-09-09 15:39:52 +02:00
David Gustafsson
b12198a53f Bug 20057: System preference for auto approval of patron profile changes
Testplan for this patch:

1. Apply patch.
2. Make sure syspref "AutoApprovePatronProfileSettings" is set to "Disable".
3. Edit patron personal details via opac interface.
4. Expect modifications to require manual approval by staff via link on main page.
5. Set syspref "AutoApprovePatronProfileSettings" to "Enable".
6. Edit patron personal details via OPAC interface again.
7. Expect modifications to have been approved automatically.

Signed-off-by: Liz Rea <liz@catalyst.net.nz>
This works, we may want some different text for this situation in the OPAC, it still says the librarian has to approve the change.

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-08-31 14:41:08 +02:00
dc0077b3a1 Bug 22844: Make the patron's attribute mandatory at the OPAC
Test plan:
- Set 1+ patron's attribute(s) mandatory
- Use the self-registration feature and confirm that you cannot selfreg
if the attribute has no value (or empty string)
- Same with the modification form (logged in)

Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-07-20 16:08:22 +02:00
73c421a516 Bug 25769: Patron self modification triggers change request for date of birth to null
If PatronSelfModificationBorrowerUnwantedField contains dateofbirth, all
patron self modification requests will attempt to set dateofbirth to
null instead of ignoring the field.

Test Plan:
1) Add dateofbirth to PatronSelfModificationBorrowerUnwantedField
2) Run a patron self modification
3) Note the request sets dateofbirth to null on the staff side
4) Apply this patch
5) Restart all the things!
6) Run another self-modification
7) Note of the staff side that dateofbirth is unaffected

Signed-off-by: Emmi Takkinen <emmi.takkinen@outlook.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-06-24 14:23:33 +02:00
Aleisha Amohia
3d022f0f27
Bug 24913: Add PatronSelfRegistrationConfirmEmail syspref
To test:
1) update database, restart memcached/plack
2) Go to Administration -> System preferences -> OPAC tab. Enable the
new PatronSelfRegistrationConfirmEmail system preference. Enable other
required self registration sysprefs.
3) Go to the OPAC home page. (You may need to log out). Click the
'Register' link so you are redirected to the member entry form.
4) Notice the 'Confirm primary email' field after the 'primary email'
field. Put 'a@a.com' in primary email, and 'b@b.com' in the confirm
field. Scroll to the end of the form and Submit.
5) Confirm the form is not successfully submitted, and an error message
is shown to indicate the email addresses do not match.
6) Confirm you cannot cut, copy or paste in either the primary email or
confirm primary email fields. Confirm the right click menu doesn't work
in these fields.

7) Disable javascript in your browser.
8) Repeat steps 3 and 4.
9) Confirm there is an error message to indicate the email addresses do
not match.

10) Re-enable javascript. Fill in the form correctly with matching email
addresses and confirm it successfully submits.

11) Disable the PatronSelfRegistrationConfirmEmail syspref.
12) Attempt to register an account on the OPAC again. Confirm the
'confirm email address' field is gone and form works as expected.
13) Re-enable the PatronSelfRegistrationConfirmEmail syspref.
14) Log in to the OPAC and go to your personal details
15) Edit the primary email field
16) Confirm you are able to submit your changes (you should not see an
error about emails not matching).

Sponsored-by: Bibliotheksservice-Zentrum Baden-Württemberg (BSZ)
Signed-off-by: holly <hc@interleaf.ie>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-04-21 12:30:40 +01:00
665c8328d1
Bug 25136: Join the 2 ifs
Highlight that we only need this for action="new"

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-04-16 19:26:48 +01:00
dbf604e141
Bug 25136: Make PatronSelfRegistrationLibraryList only effect new registration
This patch makes it so PatronSelfRegistrationLibraryList will only effect the registration from and not the modification form.
TO TEST:
1. Turn on self reg and add some libaries to PatronSelfRegistrationLibraryList.
2. Notice that the libaries that display in the borrower_branchcode dropdown are the ones you selected on both the new registration from and the modification form.
3. Apply patch.
4. Now only the new registration from should show libaries on PatronSelfRegistrationLibraryList.
5. The modifciation dropdown should still show all libraries.

Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-04-16 19:26:14 +01:00
cc6c3f5815
Bug 25137: (bug 23084 follow-up) Fix incorrect grep ternary condition
The lack of parenthesis makes the condition evaluated wrong.

Test plan:
- confirm you have a branch with code X
- enter X in PatronSelfRegistrationLibraryList
- go to cgi-bin/koha/opac-memberentry.pl (either as a logged in patron or as a self-reg patron)
- confirm branch dropdown is not empty and contain X
- empty out PatronSelfRegistrationLibraryList
- reload cgi-bin/koha/opac-memberentry.pl and confirm branches show

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-04-15 08:35:04 +01:00
37e634bb5b
Bug 20443: Remove C4::Members::AttributeTypes
We do no longer need this package, we can use
Koha::Patron::Attribute::Types directly instead.

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-03-23 13:44:41 +00:00
5dd44a8f08
Bug 20443: Remove CheckUniqueness
There is already a method in Koha::Patron::Attribute to check the
uniqueness constraint, let us it to replace CheckUniqueness

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-03-23 13:44:30 +00:00
ccfc6572f7
Bug 20443: Remove UpdateBorrowerAttribute and SetBorrowerAttributes
This patch replace Koha::Patron->get_extended_attributes with
->extended_attributes
It's now a getter a setter method.

It permits to replace UpdateBorrowerAttribute and use
create_related from DBIx::Class

Notes:
* We face the same variable names difference than in a previous patch
(value vs attribute)

Bug 20443: Remove SetBorrowerAttributes

squash  + RM get_extended_attributes

 RM get_extended_attributes

SQUASH Bug 20443: Remove UpdateBorrowerAttribute and SetBorrowerAttribute

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-03-23 13:44:16 +00:00
9707167a48
Bug 20443: Move GetBorrowerAttributes to Koha::Patron->extended_attributes
The GetBorrowerAttributes subroutine return the attributes for a given
patron.

Using get_extended_attributes we can acchieve it easily. The problematic
here is to restore the method's name (value vs attribute,
value_description vs description of the authorised value, as well as
display_checkout that should not be a method of Attribute, but
Attribute::Type instead)

value_description was used when the attribute types were attached to an
authorised value category. To avoid the necessary test in template and
controller there is now a $attribute->description method that will
display either the attribute's value OR the value of the authorised
value when needed. We should certainly use this one from few other
places.

Notes:
* This patch rename Koha::Patron->attributes with Koha::Patron->get_extended_attributes.
It will be renamed with Koha::Patron->extended_attributes in ones of the next
patches when it will become a setter as well.
* GetBorrowerAttributes did not care about the library limits, we still
do not
* The opac_only flag was not used outside of test, we drop it off.
* To maintain the existing behavior we add a default order-by clause to
the search method [code, attribute]
* From C4::Letters::_parseletter we always display the staff description
of the AV, There is now a FIXME to warn about it
* FIXMEs are not regressions, existing behaviors must be kept
* TODO add a new check to bug 21010 to search for inconsistencies in
patron's attributes attached to non-existent authorised values
* One test has been updated in Modifications.t, order_by is now
by default set to ['code', 'attribute']

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-03-23 13:39:25 +00:00
37f464e1cf
Bug 20443: Remove opac_display and opac_editable from Patron::Attribute
Same as previously for methods that have been added by bug 17792.
It's better to be explicite and tell we are fetch the related attribute's type

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-03-23 13:39:10 +00:00
3944f20beb
Bug 24892: Resolve uninitialized warns from opac-memberentry
Especially line 500 (current master).

Use of uninitialized value $new_data{"sort2"} in string eq at /usr/share/koha/opac/opac-memberentry.pl line 500.
Use of uninitialized value in string eq at /usr/share/koha/opac/opac-memberentry.pl line 500.

Simple fix, not completely trivial due to adding xor ;)

Test plan:
Do not apply, update from opac memberentry. Check warns in log.
Apply patch, update again. Less warns?

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-03-20 15:40:43 +00:00
82716a0172
Bug 23084: Replace grep {^$var$} with grep {$_ eq $var}
We certainly faced 3 similar bugs due to this syntax: bug 23006, bug
22941 and bug 17526.

To prevent other issues related to this syntax this patch suggests to
replace them all in one go.

Test plan:
Confirm that the 2 syntaxes are similar
Eyeball the patch and confirm that there is no typo!

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-02-17 10:44:45 +00:00
127dfc0b8f
Bug 19809: Remove some new occurrences
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-01-23 10:27:36 +00:00
Chris Cormack
957d583d2e
Bug 21390: Send registration verification emails immediately
To test
1/ Enable self registration
2/ Register, notice message is queued in the table but not sent
3/ Apply patch
4/ Register again, notice message is queued, but immediately sent

Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-09-17 14:51:57 +01:00
e7a84dacfe
Bug 20691: (QA follow-up) Fix self-reg
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-09-17 14:48:24 +01:00
Kyle M Hall
1ad03f5509
Bug 20691: Add ability to turn feature on and off
This patch adds two preferences
1. AllowPatronToSetFinesVisibilityForGuarantor: Allow/Don't allow patrons to choose their own privacy settings for showing the patron's fines to the patron's guarantor
2. AllowStaffToSetFinesVisibilityForGuarantor: Allow/Don't allow staff to set the ability for a patron's fines to be viewed by linked patrons in the OPAC

Also adds a tinyint, non nullable, default to 0 column in borrower and deletedborrower named privacy_guarantor_fines.
1. privacy_guarantor_fines = 0 => don't allow guarantor to see guarantee's fines
2. privacy_guarantor_fines = 1 => allow guarantor to see guarantee's fines

To test:
1) git reset --hard master
2) apply patches (including dependencies)
3) perl installer/data/mysql/updatedatabase.pl
4) dbic
5) restart_all
6) in intranet search for AllowPatronToSetFinesVisibilityForGuarantor and AllowStaffToSetFinesVisibilityForGuarantor preferences
SUCCESS => both preferences should be present
7) search for a patron with guarantor
SUCCESS => in details tab, in "Library use" section you should see a row labeled "Show fines to guarantor"
8) edit
CHECK => in Guarantor information there is no "Show fines to guarantor" select
9) set AllowStaffToSetFinesVisibilityForGuarantor preference to "Allow"
10) return to patron with guarantor and edit
SUCCESS => in Guarantor information section there is a "Show fines to guarantor" select
11) change "Show fines to guarantor" select to "Yes" and save
SUCCESS => Value is saved
12) go to details tab
SUCCESS => in "Library use" section you see a row labeled "Show fines to guarantor" with value "Yes"
13) set OPACPrivacy preference to "Allow"
14) open 2 opacs, one with a patron that has a guarantor and another that hasn't and go to "your privacy" tab.
CHECK => in both opacs you should not see a "Allow your guarantor to view your current fines?" select
15) in intranet set AllowPatronToSetFinesVisibilityForGuarantor to "Allow"
16) refresh both opacs
SUCCESS => in Patron that has guarantor you see a "Allow your guarantor to view your current fines?" select
	=> in Patron without guarantor you don't see a "Allow your guarantor to view your current fines?" select
17) in Patron with guarantor change value of select and save
SUCCESS => Value is saved
18) in intranet set OPACPrivacy preference to "Don't allow" and AllowPatronToSetFinesVisibilityForGuarantor to "Don't allow"
19) got to "your personal details" in both opacs
CHECK => in both opacs you should not see no Privacy section with a "Allow your guarantor to view your current fines?" select
20) in intranet set AllowPatronToSetFinesVisibilityForGuarantor to "Allow"
21) refresh both opacs
SUCCESS => in Patron that has guarantor you see a "Allow your guarantor to view your current fines?" select in a Privacy section
        => in Patron without guarantor there is no Privacy section
22) in Patron with guarantor change value of select and update
SUCCESS => Value is saved
23) Sign off

Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-09-11 08:53:46 +01:00
d09444c735
Bug 14570: (QA follow-up) Call Koha::Patron->find in scalar context
This patch prevents opac/opac-memberentry.pl from exploding.

To test:
- Login with a known user in the OPAC
- Open the opac/opac-memberentry.pl page
=> FAIL: It explodes
- Apply this patch
- Restart all the things just in case:
  $ restart_all
- Reload the page
=> SUCCESS: Things work!

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-08-20 16:06:31 +01:00
109334102f
Bug 14570: Make it possible to add multiple guarantors to a record
This patch adds the ability to set an unlimited number of guarantors
for a given patron. As before, each guarantor may be linked to another
Koha patron, and all the behavior that applies to a given guarantor
remains the same.

Test Plan:
 1) Apply this patch
 2) Run updatedatabase.pl
 3) Find some patrons with guarantors, verify the still have their guarantor
 4) Test adding and removing guarantors on a patron record, both Koha users and not
 5) Verify the "Add child" button works
 6) Verify NoIssuesChargeGuarantees still works
 7) Verify tools/cleanborrowers.pl will not delete a guarantor
 8) Verify the guarantors are displayed on moremember.pl
 9) Verify the guarantor is removed by members/update-child.pl
10) Verify the guarantor is removed by misc/cronjobs/j2a.pl
11) Verify import patrons converts guarantor_id, relationship, contactfirstname,
  and contactsurname into a guarantor
12) prove t/Patron.t
13) prove t/db_dependent/Circulation.t
14) prove t/db_dependent/Circulation/NoIssuesChargeGuarantees.t
15) prove t/db_dependent/Items.t
16) prove t/db_dependent/Koha/Patrons.t
17) prove t/db_dependent/Members.t
18) prove t/db_dependent/Patron/Relationships.t

Signed-off-by: Kim Peine <kmpeine@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-08-20 16:04:48 +01:00
Liz Rea
d71b263a89
Bug 23431: Don't nullify DOB if it's hidden by sysprefs
To test:

Turn on  OPACPatronDetails
put dateofbirth in PatronSelfModificationBorrowerUnwantedField
Have a patron with a set date of birth
Attempt any modification on that patron through the OPAC
The date of birth will be one of the fields changed for that borrower
when you check it in the staff intranet.

Apply this patch, repeat the above.
Date of birth will not be one of the changed fields.

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-08-08 13:04:25 +01:00
Mark Tompsett
30fd4eb1a5
Bug 23151: Tweak to use the new database structure
This will use changed_fields to know whether a
borrower field is actually modified.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-07-19 09:39:11 +01:00
6dc8306b58
Bug 23150: (follow-up) Make gdpr_proc_consent mandatory for create
When updating (patron modification), the field should not be required.

Test plan:
Check patron modification on opac.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-06-21 13:05:41 +01:00
3b14f7d636
Bug 23150: Do not consider gdpr_proc_consent a mandatory field
It introduced a regression in the patron's self modification feature.
Patron's details are no longer modificable, the screen displays
"You have not filled out all required fields. Please fill in all missing
fields and resubmit."

Test plan:
- Set GDPR_Policy to either Enforced or Permissive
- Set PatronSelfRegistrationBorrowerMandatoryField to empty
- Set OPACPatronDetails to Allow
- Log into the OPAC
- Accept the GDPR screen
- Go to opac-memberentry.pl, change something, submit modification
request

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-06-21 13:05:29 +01:00
e155e6d5bb Bug 10796: Use $category->effective_change_password in the OPAC
This patch makes the OPAC pages that rely on OpacPasswordChange use the
current patron's category to make the decision to allow password change
or not.

It does so by making sure all the places in which OpacPasswordChange was
used, use $logged_in_user->category->effective_change_password instead.

Special attention is required on the case of opac-registration-verify.pl
in which the use of an unblessed Koha::Patron object is changed in
favour of the blessed object, so we can actually use the new method to
make a decision on the text to display.

To test:
- Go through the OPAC pages, check that the password change strings and
links are displayed only whne appropriate.
- Sign off :-D

Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-04-12 02:32:07 +00:00
e0b1f945f9 Bug 21192: Do not pick SelfRegistration hidden fields for SelfModification
There was a mix up between "modification" and "edit" for $action in
opac-memberentry.pl.

If a patron is logged into the OPAC and they attempt to submit changes to their
personal details without having actually changed anything, the page reloads with
a message stating 'No changes were made.' However, the fields that now appear
are those that have been allowed/hidden according to the preferences set for
patron self registration, even if patron self registration is disabled. This can
lead to problems if there are discrepancies between the fields allowed for self
register settings and those allowed for patron self modification settings.

To replicate:

1.) In Administration › System preferences > OPAC, set PatronSelfRegistration to
'don't allow'

2.) Modify the unwanted fields for PatronSelfModificationBorrowerUnwantedField
and PatronSelfRegistrationBorrowerUnwantedField so that at least one field is
different between the two settings and save (for example, specify 'mobile' to be
hidden in the former, but don't include in the list of fields to be hidden in
the latter).

3.) Log into the OPAC and navigate to the 'your personal details' tab. Notice
that the editable fields correspond to those not hidden by
PatronSelfModificationBorrowerUnwantedField

4.) Without making any changes, click on 'Submit update request'.

5.) Note that on this page the fields correspond to those not hidden by
PatronSelfRegistrationBorrowerUnwantedField and are now editable (including any
fields that would otherwise be hidden by the Self Modification settings).

Reported-By: Chris Slone <cslone@camdencountylibrary.org>
Signed-off-by: Devinim <kohadevinim@devinim.com.tr>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-01-18 20:39:47 +00:00
f6eb461516 Bug 20819: Add consent to self-registration process
We add a section for the GDPR consent in opac-memberentry (only for the
self-registration). Not when editing personal details.

Test plan:
[1] Enable selfregistration (with confirm) and GDPR policy.
[2] Register a new account in OPAC. Verify that the GDPR checkbox is
    required.
[3] After you submit, you should see a date in borrower_modifications
    field gdpr_proc_consent.
[4] When you confirm, verify that the consent is visible on your consents.
[5] Enable selfregistration without confirmation mail. Register again.
[6] Check your consents tab again.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-09-20 13:45:26 +00:00
cfbc53bb22 Bug 20287: Add plain_text_password (& Remove AddMember_Opac)
But actually we could remove it if it does not make sense for other use.
Callers could deal with it since the password is not generated here

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-07-18 15:49:49 +00:00
dc6b6e030c Bug 20287: Remove AddMember_Auto
I am not sure I understood the point of this subroutine.
Did I miss something here?

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-07-18 15:49:49 +00:00
7809a6bd13 Bug 18403: Add new methods Koha::Patrons->search_limited and use it where needed
Most of the time when we search for patrons we do not want to search for all patrons,
but just the ones the logged in user is allowed to see the information.
This patch takes care of that by adding a new search_limited method to Koha::Patrons.
When called this method only search for patrons that the logged in user is allowed
to see.

Test plan:
Patron autocomplete search should be limited

Signed-off-by: Signed-off-by: Jon McGowan <jon.mcgowan@ptfs-europe.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2018-02-12 15:41:39 -03:00
8ba6bd033f Bug 19989: remove confusing variable
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2018-02-05 09:45:46 -03:00
Zoe Bennett
0f3fef5cae Bug 19989: Use Koha::Patron::Modifications->delete instead of loop
Test:
1) Make a change to the user in the OPAC
2) In the staff client make sure this is the only request

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2018-02-05 09:44:55 -03:00
579507e7f7 Bug 19911: Do not escape html characters when saving passwords
When the password is not generated automatically, we should not escape
the html characters. Otherwise it will be changed without any warnings.

Signed-off-by: Arturo <alongoria@sll.texas.gov>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2018-01-15 12:13:59 -03:00
325fddd8e9 Bug 19845: Do not generate a password if one is filled on selfreg
Bug 15343 allows patrons to choose their own passwords during self-registration.
But this does not work if the PatronSelfRegistrationVerifyByEmail preference is
set to "Require." If e-mail verification is required, whatever password the patron
supplied in the form is ignored, and they are given a randomly generated password
once they click on the verification link.

Test plan:
1. Make sure there is a valid e-mail stored in the KohaAdminEmailAddress preference.
2. Set PatronSelfRegistration to Allow.
3. Set PatronSelfRegistrationVerifyByEmail to Require.
3. Be sure "password" is listed in PatronSelfRegistrationBorrowerMandatoryField and
NOT listed in PatronSelfRegistrationBorrowerUnwantedField.
4. Be sure there is a valid patron category in PatronSelfRegistrationDefaultCategory.
5. Set PatronSelfRegistrationPrefillForm to "Display and prefill" so that you can see
the generated password.

Then fill out the self-registration form, include a valid e-mail address, and select
a password. Wait for the verification e-mail. Click on the link and you'll see that
the password you entered in the form is used.

Signed-off-by: Arturo <alongoria@sll.texas.gov>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-12-21 13:07:54 -03:00
3f9da34683 Bug 18298: Add server-side checks and refactor stuffs
Now that we have a check client-side, nothing prevents us from a smart guy to
bypass it and force an invalid password.
This patch adds two new subroutines to Koha::AuthUtils to check the
validity of passwords and generate a password server-side. It is used
only once (self-registration) but could be useful later.

Moreover the 3 different cases of password rejection (too leak, too
short, contains leading or trailing whitespaces) were not tested
everywhere. Now they are!

This patch makes things consistent everywhere and clean up some code.

Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-10-16 09:44:32 -03:00
ec4e666bc5 Bug 18298: minPaswordLength should not be < 3
Indeed if RequireStrongPassword is set we need at least 3 characters to
match 1 upper, 1 lower and 1 digit.
We could make things more complicated to allow minPasswordLength < 3
but, really, 3 is already too low...

Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-10-16 09:44:32 -03:00
ae02cf97e4 Bug 19366: Do not block patron's detail update if EmailMustBeUnique
If the pref PatronSelfRegistrationEmailMustBeUnique is set ("consider"),
a patron is not allowed to register with an existing email address.
The existing code is wrong and reject a patron that is updating their
personal details with "This email address already exists in our
database.", even if the patron did not modify their email address.

This is caused by the query we made, we must search for patron with this
email address but who is not the current patron.

Test plan:
- Set PatronSelfRegistrationEmailMustBeUnique to "consider"
- Register a new patron with an existing email address
=> you should not be allowed
- Use a non-existent email address
=> You should be allowed
- Edit your patron details
- Modify some infos
=> Should pass
- Modify your email address with an existing one
=> You should not be allowed to do that

Followed test plan, patches worked as described
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-09-29 12:36:59 -03:00
2b90ea2cb0 Bug 17829: Move GetMember to Koha::Patron
GetMember returned a patron given a borrowernumber, cardnumber or
userid.
All of these 3 attributes are defined as a unique key at the DB level
and so we can use Koha::Patrons->find to replace this subroutine.
Additionaly GetMember set category_type and description.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-07-10 13:14:19 -03:00
f7b11f38e8 Bug 17762: Send lang to GetPreparedLetter
This patch set the lang parameter when C4::Letters::GetPreparedLetter is
called to generate the notice.
Note that we do not need to pass it if want_librarian is set.

TODO: I do not know what to do with TransferSlip

Sponsored-by: Orex Digital

Signed-off-by: Hugo Agud <hagud@orex.es>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2017-05-09 20:56:41 +00:00
574d48362d Bug 18124: Change the calls to generate and check CSRF tokens
The parameter change in Koha::Token should be applied to the calling
scripts.

Test plan:
Confirm that the different forms of the scripts modified by this patch
still work correctly.

Test the problematic behavior:
Open 2 tabs with in same user's session, go on the edit patron page
(memberentry.pl).
Log out and log in from the other tab.
Submit the form
=> Wrong CSRF token should be raised

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2017-03-30 09:07:09 +00:00
e06c193187 Bug 13757: (QA followup) Filter out non-editable params before storing
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2017-03-24 18:45:22 +00:00
ec9ac4d7b9 Bug 13757: (QA followup) Exclude empty attributes from rendering if non-editable
In self registration opac displayable (and not editable) attributes are
displayed as empty. This an empty value is passed to the template for
creating an empty input and it shouldn't when the attribute is not
editable.

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2017-03-24 18:45:21 +00:00
e63e4bb35a Bug 13757: (QA followup) Fix non-editable attrs on failed save
When a field is not editable but displayable in the OPAC, and you submit
an incomplete/wrong update, those attributes are displayed as empty.

This patch fixes that.

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2017-03-24 18:45:14 +00:00
c44a377d9c Bug 13757: (QA followup) Make opac-memberentry.pl handle attrs deletion
The original code on this bug skipped empty-valued attributes. But
emptying attributes is the only way to tell the controller script that
the user wants to delete them.

This patch makes opac-memberentry.pl check the existence of attributes
sharing the code of the empty for the given patron, and it stores the
deletion on the Koha::Patron::Modification as needed. Otherwise
deletions got skipped.

To test:
- Verify setting/deleting attributes that are opac-editable and verify
the results are sound.

https://bugs.koha-community.org/show_bug.cgi?id=13737

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2017-03-24 18:45:13 +00:00
925e664f42 Bug 13757: (followup) Staff interface changes
This patch adds proper extended attributes display and handling on the
patron modifications moderation page (members-update.pl).

It also adds changes checking to the opac-memberentry.pl page so it
only saves a modification request if there are changes (it only checked
regular fields and not the extended ones).

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2017-03-24 18:44:59 +00:00
bfa3f41032 Bug 13757: (followup) Remove warnings
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2017-03-24 18:44:58 +00:00
01506e0195 Bug 13757: Add extended attributes to the patron modification
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2017-03-24 18:44:57 +00:00