YA deactivated accounts

Posted: Sun Oct 26, 2008 10:00 am

I must have my picky hat on this morning.

How does this YA deactivation work?

I was hoping it would drop the number of overall membership, but alas, after deactivating a test account the overall in the info block remains the same.

And how does one reactivate the account?

Also, when the test user attempts to login after deactivation, they see the "Your Account has been deactivated" string. It seems a little abrupt, so, I'm going to change my language file so it reads "Your account has been deactivated. Contact admin at mydomain com"

Posted: Sun Oct 26, 2008 11:15 am

When you deactivate someone their real name field gets changed to Member Deactivated and they show up in the Deactivated Users tab as well as in the regular users tab but not in the active users tab. You have to go in and remove the user to bring about a change in the user count in site info. There is no way to reactivate the account -- at least short of phpmyadmin.

There was some discussion of this during the testing of RNYA but we wanted to leave the basic functioning alone wherever possible. Probably there should be a way to reactivate but we'd have to look closely at the code to see if anything else happens besides flipping a status field during deactivation. Probably, if you ask me, there should be a one step removal too.

Not a picky hat at all, it's a good question and probably points out an issue that should be addressed for RN 2.4.

Posted: Sun Oct 26, 2008 11:33 am

If you Suspend the user, you can re-activate the user account but once they are de-activated, they are in limbo until you open the airlock and throw them into space and thats the only place they can go.
Whilst your here, note also that the 'Waiting users' shown in the Waiting Content block refers to 'account waiting for users to activate them'.
If you have configured RNYA to admin approve user registrations, when you approve them, they will still show as 'waiting' until the user actually activates their account.

Posted: Sun Oct 26, 2008 12:58 pm

hmmm...
I vote for leaving their real name alone and some ability to reactivate besides using phpmyadmin to change the user_active table. Which doesn't work for me and the user still can't login (IE). I haven't checked, but I'm assuming to change the value of user_active doesn't change anything else, ie: forum posts? Or does it? What's most important atm, if I want to reactivate a user, how can I do it using phpmyadmin?

question: what's with the tables user_lastvisit and lastsitevisit? Is one for forums and one for YA?

Thanks for the heads up Guardian ... it's like the PM outbox.

Posted: Mon Oct 27, 2008 12:57 pm

I'm spelunking around in the code to try to answer this. It looks like deactivation was originally part of a delete user function. If you look at the programs in the YA/admin directory there is a program for every purpose but not one for deactivation. What you do wind up going into is deletuser.php and then deleteuserconf.php. Once you've confirmed the "deactivation" the actual sql that does it is:

Code:

 $db->sql_query("UPDATE ".$user_prefix."_users SET name='"._MEMDEL."', user_password='', user_website='', user_sig='', user_level='-1', user_active='0', user_allow_pm='0', points='0' WHERE user_id='$del_uid'");

The _MEMDEL constant is defined (English) as "Member Deactivated" so that's why we are seeing that. So basically once you've said to deactivate the user that user id is "trashed". There's no password any more for instance. It looks like in PHPmyadmin you'd have to set user_active back to 1 and also user_level back to 1.

I just did that on a deactivated user on my test site. It undeactivates them but still their password and name are going to be missing. In short this is not recommended.

You would be better off not to deactivate someone unless you are also planning to remove them entirely. Then let them recreate a user id from scratch if you want them back in.

Just to complete the picture ... the remove user confirm program cleans up after deactivated users. It does this:

Code:

  $db->sql_query("DELETE FROM ".$user_prefix."_users WHERE user_id='$rem_uid'");


  $db->sql_query("DELETE FROM ".$user_prefix."_users_field_values WHERE uid='$rem_uid'");


  $db->sql_query("DELETE FROM ".$user_prefix."_users_temp_field_values WHERE uid='$rem_uid'")

Then optimizes the three tables. I think it would be good practice to always remove any user that you are deactivating.

For 2.4 we could discuss changing this whole behavior. But for right now deactivate is tantamount to delete.

However, suspend user looks like it does what you want. When you suspend a user what you get is:

Code:

  $db->sql_query("UPDATE ".$user_prefix."_users SET user_level='0', user_active='0' WHERE user_id='$sus_uid'");

and then on the suspended users tab there is a handy restore user option.

So: in practice ... consider deactivation a precursor to deletion and non-restoreable. Consider suspension where you want to be able to restore the user.

Posted: Mon Oct 27, 2008 3:36 pm

Thanks for the clarity fkelly! So, if I want to reactivate my deactivated user, in phpmyadmin I need to change : real name, password, user_active and user level.

That works! Wink

Posted: Mon Oct 27, 2008 6:30 pm

It probably works, for sure. And if the user was deactivated by mistake it might be okay in an isolated case. Otherwise I'd recommend: deactivate -- delete or suspend and restore.

Posted: Mon Oct 27, 2008 6:37 pm

I think the term suspend sounds a bit punitive, it is associated with something bad happening, like being suspended from school.

On one of my sites, users would like to know how many active members there are ... ie: how many users out of 1000+ have actually logged in in the past couple of years. They would me like to deactivate members who have not logged in in two years, but be able to activate them in some future. I was hoping deactivate would do the trick, but it doesn't. And suspend sounds punitive. Sheesh, these users think I can do magic. Smile

Thanks for the help!

Posted: Mon Oct 27, 2008 6:49 pm

I guess that is the problem you get with all the options now available in RNYA. I am sure as time goes on we can smooth out the terminology as well as the operation of the system. There are some last visited fields or something like that in the users table. I just don't know how reliable they are. If they are (and I doubt it) you could write a block to show what percentage or what absolute number (or both) of your users had logged in during given past time spans. Unless we first validated that the data was good writing the block would be a waste of time. And even then it might be. It would be much better (IMHO) to have an admin application that would periodically fire off an email to all users (or piggyback on any mass email sent through HTML newsletter) and delete the accounts of anyone whose email is undeliverable.

registered · Site Admin Joined: Jun 04, 2004 Posts: 6437

There are 2 last visited fields in the users table, and they are consistently updated for their intended purposes.

The original field was updated on registration and when viewing forums. Because the original field impacts the display of new posts since the last forum visit, we added the new field in RNYA to be updated each time the user visits the site for display on the user list.