Bug 19660 - Set borrower password on first login from self registration
Summary: Set borrower password on first login from self registration
Status: Failed QA
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Marcel de Rooy
URL:
Keywords: Academy
Depends on:
Blocks:
 
Reported: 2017-11-21 03:27 UTC by Liz Rea
Modified: 2023-10-03 11:06 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug-19660: Set password after self registration (16.31 KB, patch)
2018-01-17 03:43 UTC, jwayway
Details | Diff | Splinter Review
Bug-19960: Fix password field (3.11 KB, patch)
2018-01-18 22:45 UTC, jwayway
Details | Diff | Splinter Review
Bug 19660: Set password after self registration (16.42 KB, patch)
2018-03-15 01:05 UTC, Mark Tompsett
Details | Diff | Splinter Review
Bug 19660: Follow up to fix password field on the registration page (3.23 KB, patch)
2018-03-15 01:05 UTC, Mark Tompsett
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Liz Rea 2017-11-21 03:27:45 UTC
Currently when a borrower has confirmed their account, we show them their username and password after confirmation. I propose instead of doing this, we allow the user to set their own password after they have confirmed their account. 

We could use parts of the forgot-my-password code to do this, for example pre-populating the username/email bits of the form, and asking the user to fill in their new password twice.

We really shouldn't be showing the password on the screen, ever. Let's not do that anymore.
Comment 1 jwayway 2018-01-17 03:43:35 UTC Comment hidden (obsolete)
Comment 2 jwayway 2018-01-18 22:45:15 UTC Comment hidden (obsolete)
Comment 3 Laurence Rault 2018-03-13 15:43:55 UTC
Tested ok following test plan, ready to be signeoff

Impossible to signoff from the sandbox : 
It seems you don't have applied a patch, so you cannot sign it off. If you applied patches from the right report, check the commit message of the last patch. It should start with "Bug XXXXX", if not, please inform the author of the patch.
Comment 4 Mark Tompsett 2018-03-15 01:01:54 UTC
These system preferences need setting from a base kohadevbox:
OpacResetPassword - Allowed -- otherwise you get almost done, and then it won't let you check it, because reset isn't allowed.

PatronSelfRegistration - Allow -- otherwise, you can't even start.
PatronSelfRegistrationDefaultCategory - Anything valid, otherwise you may have a crash somewhere.

PatronSelfRegistrationPrefillForm -- MMmmm... something isn't right with this now.

It works as expected, but something about this leaves a bad taste in my mouth.
Comment 5 Mark Tompsett 2018-03-15 01:05:50 UTC
Created attachment 72900 [details] [review]
Bug 19660: Set password after self registration

Test plan:
1. Enable PatronSelfRegistration
2. Add a PatronSelfRegistrationDefaultCategory too
3. In OPAC register a user
4. Without patch after hitting submit, password is displayed onscreen
5. After applying patch, password is changed afterwards by sending a
email
6. Note how primary email is required

Notes
- Email is now required for this to work since a unique key was needed
for password-recovery.pl to work
- A password is randomly generated for the user

Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Comment 6 Mark Tompsett 2018-03-15 01:05:53 UTC
Created attachment 72901 [details] [review]
Bug 19660: Follow up to fix password field on the registration page

This is a follow up patch to fix the password field on the registration
complete page.
Please upload this patch along with the previous version :)
Test plan:
1. Apply this patch
2. The password field has the pregenerated password if the syspref is
enabled
3. Before the patch the password was displayed on the screen in a span
tag

Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Comment 7 Marcel de Rooy 2018-04-20 06:38:17 UTC
vertification_legend ?
Comment 8 Marcel de Rooy 2018-04-20 06:41:08 UTC
QA: Looking here
Comment 9 Marcel de Rooy 2018-04-20 07:30:19 UTC
I have the feeling that we are not ready yet.

As Mark already stated, this feature does not work when pref ResetPassword has not been enabled. But since that is possible, we should make it work somehow?
Currently when off, you can enter your email address. You will directly see: You can't reset your password. But I also got an email with a reset link. Clicking that link gives also: You can't reset your password.

Apart from ResetPassword dependence, if the registration is complete, I think that the form is still a bit confusing. Entering an email is optional and password is prefilled. If I just click Login, I am in but I do not know my password. Why don't we add a New password field on the Completion form? Then the user is forced to enter a new password AND we do not rely on the Reset functionality that may be disabled altogether? (Or add the password already on the first registraton form memberentry?)

Note that without digging thru all registration options, I got the option to create a Staff user in the self registration form. I think we should not offer that. Outside scope here though.

Changing status.
Comment 10 Agnes Rivers-Moore 2018-04-30 18:05:47 UTC
Librarian point of view - 
As M Tomsett says, this method cannot work properly without an email address. The email field should not be required - especially now with so many countries requiring specific opt-in permission from the user to send them email.
However, it should be possible for people to use online services without giving an email address. 
I agree with Marcel that the ideal solution is to have the user enter password (hidden, twice for verification) in the registration form. Then, let the email address be optional, as a library set preference.
Comment 11 Katrin Fischer 2023-10-01 13:05:39 UTC
(In reply to Agnes Rivers-Moore from comment #10)
> Librarian point of view - 
> As M Tomsett says, this method cannot work properly without an email
> address. The email field should not be required - especially now with so
> many countries requiring specific opt-in permission from the user to send
> them email.
> However, it should be possible for people to use online services without
> giving an email address. 
> I agree with Marcel that the ideal solution is to have the user enter
> password (hidden, twice for verification) in the registration form. Then,
> let the email address be optional, as a library set preference.

The problem with an optional email address on self registration is that you have no means to verify that the user registering is a real person. It would open self registrations up to bots and pranks.
Comment 12 Agnes Rivers-Moore 2023-10-02 15:26:46 UTC
(In reply to Katrin Fischer from comment #11)
> (In reply to Agnes Rivers-Moore from comment #10)
> > Librarian point of view - 
> > As M Tomsett says, this method cannot work properly without an email
> > address. The email field should not be required - especially now with so
> > many countries requiring specific opt-in permission from the user to send
> > them email.
> > However, it should be possible for people to use online services without
> > giving an email address. 
> > I agree with Marcel that the ideal solution is to have the user enter
> > password (hidden, twice for verification) in the registration form. Then,
> > let the email address be optional, as a library set preference.
> 
> The problem with an optional email address on self registration is that you
> have no means to verify that the user registering is a real person. It would
> open self registrations up to bots and pranks.

I am not sure existence of an email address proves a genuine individual or protects from pranking or misuse. If a library needs to prove there is a real person who is not already registered, or banned, or from another country, they would need more than an email address. Our staff see the online registration attempt and contact the person for ID verification. So, library set preference for whether email is required or not. For us, phone number required is more important.
Comment 13 Marcel de Rooy 2023-10-03 11:06:54 UTC
(In reply to Agnes Rivers-Moore from comment #12)
> I am not sure existence of an email address proves a genuine individual or
> protects from pranking or misuse. If a library needs to prove there is a
> real person who is not already registered, or banned, or from another
> country, they would need more than an email address. Our staff see the
> online registration attempt and contact the person for ID verification. So,
> library set preference for whether email is required or not. For us, phone
> number required is more important.

If you enable the verification step for self registration (and imo you should always do that), you need an email address.