Forum OpenACS Q&A: Registering users with post-facto email address checks...?

I believe the user registration state machine in 3.2.5 (I don't know
about 4) allows user's to be registered immediately, or requires
users to have an email address checked. (https://openacs.org/doc/user-registration.html)

I prefer my user's to have valid email addresses, but I want to
reward them for taking the effort to register at all.  Requiring the
email check breaks certain ACS/user behaviors, specifically, the
ability to start an activity, be asked to login and then be
automatically returned to the interrupted activity.  Examining logs
show that often times, users start an activity, are forced to
register, and then abandon their initial activity.  That's not good
for building users and traffic.

Has anyone implemented a process in which users are registered, and
accepted as "interim" users, and then at a later time are asked to
verify their email address or else be banned from the system?  And
what does the OpenACS 4 user registration process look like?

Thanks,

OpenForce implemented something similar to this for
GreenOrder, although not quite what you're talking about.
However, what you're talking about is pretty easy to do. You can
have a scheduled proc that checks for users who fit your "this
guy now needs to verify his email address" check (days since
registration, etc...), and updates the user_state to
needs_email_verification. OpenACS 3.2.5 will gracefully handle
this the next time the person logs in. The one thing I'm not *
certain* about is exactly what happens if the user is permanently
logged in... you might have to hack something there.
Thanks Ben, it's always good to know what others have done.

Just to clarify: the users start out in state authorized, your proc moves them from state authorized to state needs_email_verification and then OpenACS and their email verification move them back to state authorized?

That's not exactly what our system does, because we go through
some weird checks for pre-approved sets of email address
(government and such) and what type of user they are (supplier).
But what happened is that we had an open site with no email
verification for a few months. Then we added email verification,
and the way we did that is that we simply updated the state of all
existing users in the DB to need_email_verification.

Now, we had custom login scripts, so our scripts handled that
new state, but I am 99% sure that the generic OpenACS login
scripts would do the right thing, too.

How about authorizing the user immediately, send them
an automatic welcome email with a coded url requesting them to click on the link that flags the db that the email is valid.

If they don't do this in x days. the account automatically
deleted.

This way, the user can stay logged on and still have
their account deleted if the email isn't confirmed

We may implement something like this soon.

Yes, I just took a lunch break and came to that thought too.  As you suggest -- ask them to register, send out the email, authorize them immediately, and then force them to need email verification if they haven't responded within a week.  I think we can check by checking the email_verified_date.

And that should work, although intriguingly, uh bugifyingly, when I scan the users table on one of the systems I admin, I can see that there are users in state authorized that have a null email_verified_date.  This suggests to me a bug somewhere within the OpenACS 3.2.5 registration system -- this system has always insisted users verify their email address.

Another step I might suggest to enhance the user experience a bit is  to send a second email with the encoded URL at the time the system determines he/she has not responded to the first... in case the first was accidentally deleted, missed, etc.

So if the user hasn't replied to the verification email in X days send a polite reminder that if they don't respond to this one their account will be moved to "require verification" or removed.

A simple popup reminder to check their email each time they start a new session until verification occurs may be effective also.