Bug 23908 - Require patrons to confirm their email address
Summary: Require patrons to confirm their email address
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement with 10 votes (vote)
Assignee: Martin Renvoize
QA Contact: Testopia
URL:
Keywords:
: 28357 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-10-28 08:55 UTC by paxed
Modified: 2023-12-28 17:48 UTC (History)
8 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description paxed 2019-10-28 08:55:29 UTC
Koha should require patrons to confirm their email address (by sending a confirmation email to the address) when the email is changed. This would prevent typos.
Comment 1 Katrin Fischer 2019-10-28 08:56:49 UTC
Should we prevent sending email to unverfiied emails? (optionally)
How should the patron import behave here? Checkbox for sending out verification emails vs. importing them as "verified"?
Comment 2 Lari Taskula 2019-10-28 12:34:50 UTC
(In reply to Katrin Fischer from comment #1)
> Should we prevent sending email to unverfiied emails? (optionally)

If verification is on and required, I think this is expected behavior in order to avoid emails ending up in wrong person's inbox. Why not just force it when verification is turned on?

> How should the patron import behave here? Checkbox for sending out
> verification emails vs. importing them as "verified"?

Having a choice for import is a good idea. We should also discuss what happens when this feature is applied. Send verification to everyone or consider existing patron emails verified?

Also, we should keep using their old email for messaging until patron has verified the new one. So this requires some thought for the design. Perhaps the whole messaging system should be redesigned so that patron can add n number of email addresses (that can actually be used for messaging according to patron's choice) instead of the so-confusing email, emailpro, B_email and so on. But maybe this is outside the scope of this Bug.
Comment 3 Katrin Fischer 2021-06-03 22:37:31 UTC
*** Bug 28357 has been marked as a duplicate of this bug. ***
Comment 4 Katrin Fischer 2021-06-03 22:37:42 UTC
(In reply to Christopher Brannon from comment #0)
> Dead e-mails are a pain to deal with.
> 
> It would be great if e-mail notifications were verified, regardless of
> registering online or in person.  If an e-mail address is entered by staff,
> Koha should have a flag to indicate if the address has been verified.  When
> an account is saved or updated, it should check if an e-mail address has
> been entered.  If so, if it has not been verified, it should send a
> verification e-mail to the address.  When the patron receives it, they
> should have to click something or login to complete the verification.  The
> address is marked in their account as verified.  If the address is changed
> at all, they have to re-verify.
> 
> Staff who receive notice that the e-mail has problems (dead, full, etc)
> should have a flag they can set on the account to mark the address as bad,
> and the reason why.  The patron would then have to supply a new e-mail
> address and verify again.  While the account is flagged with a bad e-mail,
> notifications to that address should be turned off.  If they have another
> form of notification, Koha could send them a notification that the e-mail
> address they supplied is no longer working, and needs to be corrected.
Comment 5 David Cook 2021-06-03 23:31:52 UTC
So Keycloak (the open source Identity and Access Management software) has an "Email verified" attribute for users, and there are several ways that it can be enabled.

Administrators can manually enable it, a registration email can include an email verification link, you can update it using a REST API. Those are the methods I know of but there might be more.

--

In theory, when importing patrons, any patron may or may not have a verified email address. So I think you just include it as a patron attribute when importing.
Comment 6 David Cook 2021-06-03 23:36:09 UTC
(In reply to Lari Taskula from comment #2)
> Also, we should keep using their old email for messaging until patron has
> verified the new one. So this requires some thought for the design. Perhaps
> the whole messaging system should be redesigned so that patron can add n
> number of email addresses (that can actually be used for messaging according
> to patron's choice) instead of the so-confusing email, emailpro, B_email and
> so on. But maybe this is outside the scope of this Bug.

This is something I've been saying for years. I haven't found an existing bug for it, but I also haven't looked super heard.

Interesting that people used to pack multiple emails into some of these email fields though (see Bug 16786).