Bug 29291 - Link self registration verification email to patron account after verification
Summary: Link self registration verification email to patron account after verification
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-10-20 21:47 UTC by Christopher Brannon
Modified: 2023-12-06 18:31 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Brannon 2021-10-20 21:47:40 UTC
It would be great if the self registration e-mail verification was stored in the notifications.  Any password that might be in the message could be masked in storage.  Or the message itself could be masked.  We would at least have a record of the attempt.
Comment 1 David Cook 2023-11-30 00:30:42 UTC
I think this might be outdated. I've noticed the OPAC_REG_VERIFY email in message_queue
Comment 2 David Cook 2023-11-30 00:30:55 UTC
(In reply to David Cook from comment #1)
> I think this might be outdated. I've noticed the OPAC_REG_VERIFY email in
> message_queue

Observed in Koha 22.11 that is
Comment 3 Katrin Fischer 2023-11-30 21:57:55 UTC
There cannot be any password in the message thankfully. Maybe the misunderstanding is that it's not linked to the patron yet via borrowernumber and thus not showing on the notices tab. The patron doesn't have a borrowernumber until they click the verification link.
Comment 4 Christopher Brannon 2023-12-04 22:58:54 UTC
I don't think I am being understood here.  I am not talking about the template of OPAC_REG_VERIFY.  That is all well and good.  What I am not seeing is a copy of the email sent to the patron in notices.pl.  It would be great if we could see what was sent out here, and when it was sent.  It would also be great if we could resend it, if they missed their window of time to respond.
Comment 5 David Cook 2023-12-04 23:14:31 UTC
(In reply to Christopher Brannon from comment #4)
> I don't think I am being understood here.  I am not talking about the
> template of OPAC_REG_VERIFY.  That is all well and good.  What I am not
> seeing is a copy of the email sent to the patron in notices.pl.  It would be
> great if we could see what was sent out here, and when it was sent.  It
> would also be great if we could resend it, if they missed their window of
> time to respond.

You're misunderstanding Katrin's comment. The email doesn't appear in notices.pl because it's not linked to the patron by borrowernumber, since the patron and its borrowernumber doesn't exist until after they verify the registration.

You could see the information via a SQL report, but it's true there's no way of resending it, although the window to respond out of the box is 14 days. If they haven't signed up in that time, I think it's reasonable to have them try to self-register again.

I don't really see this one changing, but I suppose it's possible someone could sponsor an enhancement that provides a UI for an administrator to see all emails in the message_queue and lets them resend whatever they want. 

But I think that would different to "Self Registration e-mail verification is not stored in notices".
Comment 6 Katrin Fischer 2023-12-05 21:05:37 UTC
Thanks David, that's what I was trying to say.

The account doesn't exist yet, so we cannot show it in the notice tab. It's still in the message_queue table but with borrowernumber NULL. 

We do have a record of the attempt.

I just verified this in a 22.11 installation.
Comment 7 Christopher Brannon 2023-12-05 22:46:01 UTC
Okay, I think I understand now.  Until they verify, the account isn't created?  So, forgive me for not walking through the process.  Are they asked to create a login before they provide all the information and email address?  If not, where is all their information stored until the email address is validated?  I'm just trying to understand which comes first, email validation, or the storage of their self registration information.

And maybe this needs to morph into a different subject/title, but what if an email address is changed or added later, either by staff or patron.  It seems that right now the only validation happening is at registration, but no other time.  It seems that we need to work towards adding this notification to notices.pl, if not for this specific instance, but for the possibility of validating addresses at some other point.  I know.  I am putting the cart before the horse here.

But back to my question.  Is there no patron info stored before the validation email goes out?
Comment 8 Katrin Fischer 2023-12-05 22:52:29 UTC
(In reply to Christopher Brannon from comment #7)
> Okay, I think I understand now.  Until they verify, the account isn't
> created?  So, forgive me for not walking through the process.  Are they
> asked to create a login before they provide all the information and email
> address?  If not, where is all their information stored until the email
> address is validated?  I'm just trying to understand which comes first,
> email validation, or the storage of their self registration information.

The data is stored in borrower_modifications.
They provide an email address when registering, it's mandatory when using email verification and is used to send the email.
They don't need to create a login right away, they will be able to enter a password after clicking on the verification link in the email, at which time the account is created and the data moved to borrowers.

> And maybe this needs to morph into a different subject/title, but what if an
> email address is changed or added later, either by staff or patron.  It
> seems that right now the only validation happening is at registration, but
> no other time.  It seems that we need to work towards adding this
> notification to notices.pl, if not for this specific instance, but for the
> possibility of validating addresses at some other point.  I know.  I am
> putting the cart before the horse here.
> 
> But back to my question.  Is there no patron info stored before the
> validation email goes out?

See above. Everything they enter in the self registration form is stored, but in borrower_modifications. There is a cronjob option to delete data of unverified registrations to clean that up regularly.

There are already other bugs for email/patron verification. 

Bug 33633 - Check if email exists
Bug 26166 - Patron verification through SMS one time code 
Bug 32136 - E-mail testing
Bug 23908 - Require patrons to confirm their email address

Can we now keep this one closed? ;)
Comment 9 Christopher Brannon 2023-12-05 23:06:01 UTC
Well, you keep closing it, and I would like to keep it open for discussion, but I'm not given that option when you close it.  I think this is something we should work on.  I don't think this notification has to slip through the cracks in the process.  It seems to me, if this information is kept in borrower_modifications, we could find some way of tying the email to this information.

Regardless of whether the email serves a functional purpose in notices.pl, it serves us to keep a record of communications.  Having this piece slip through the cracks because the account can't be created until they respond is not enough of a reason to not keep record of it where staff can see it.

I know, it isn't crucial, but it would be more thorough to put this in the notices.pl after the account is validated.
Comment 10 Katrin Fischer 2023-12-05 23:45:39 UTC
I changed the bug description. I think at the moment we don't have good enough information to reliably link. Maybe keeping the letter_id in borrower_modifications could be a way.
Comment 11 Christopher Brannon 2023-12-06 15:46:56 UTC
Thank you for hearing me out on this, and putting up with my noise.  Just trying to make the most sense out of all of this.
Comment 12 Katrin Fischer 2023-12-06 18:31:20 UTC
(In reply to Christopher Brannon from comment #11)
> Thank you for hearing me out on this, and putting up with my noise.  Just
> trying to make the most sense out of all of this.

I think I could have done a bit better here. Glad we came to a solution.