• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Add-on Self-deactivate account

Floyd R Turbo

Well-known member
#1
I don't want to allow users to delete their own account. I don't really want to delete an account with any content either

What I want to do is allow for "deactivation" of a user account in a way that is similar to banning, without actually banning them

It would allow them to re-activate their account in the future. Basically, a "deactivate" button that rolls over to "re-activate" when an account is deactivated.

Right now, I have to create a user group "requested delete" and then change their user state to "email invalid (bounced)"

Looking for a grander solution
 

dihuta

Formerly Dinh Thanh
#4
Account Banning is used for Something wrong with users.
Account Deleting is used for Spammer or By User request.
Deactivating is similar to Account Deleting but We or users can undo it (re-activating) anytime. No data would be lost.
 

Floyd R Turbo

Well-known member
#5
We have a hobbyist club. Sometimes people get out of the hobby or move but are still getting messages, and want them to stop. Instead of them doing things like reporting as spam and hurting deliverability, or bugging me or another admin to "stop sending emails" we would like to automate the functionality of the work-around we have in place.

We have other times where someone decides they don't want to be part of the club anymore for one reason or another. Under our old forum (DNN ActiveForums) there was a built-in feature that allowed one to self-delete an account, but it kept their posts around, attributed to them, profile viewable, but you couldn't send them a PM

We don't delete anything. We don't want to delete accounts.

We would like to be able to retain a user's info/profile, etc - the ability to search their posts, see threads they've started, etc.

Another thing would be a notation in things like possibly their signature, custom user title, etc that said "deactivated account" or "inactive account", which would then be reverted should they decide in the future to reactivate.

Yet another feature would be the ability to reactivate an old account using a different email address. This would hit another issue we have where user passwords on all accounts were wiped on conversion, someone might have an old account using an email address they don't have access to anymore, so their account is essentially only manually accessible - they have to reach out to me to change the email so they can reset the password, or they just create a new account thinking their old account is lost.

So another feature would include, when attempting to reactivate an old account, if they could not remember their old username and/or email address, they would be overtly given this option (with some kind of direction/explanation) to contact the administration to locate and validate their old account (like entering in possible user names and/or email addresses so we can help)

Such a thing would be needed for anyone else using this addon that is not in our shoes - coming back to a forum a few years after deactivation. So it's not just a feature we need.
 

Floyd R Turbo

Well-known member
#7
Ok here is my first stab at requirements list:

User deactivation functionality

1) On user's Account Details page, add a section under Settings: Deactivate Account

2) The Deactivate Account page would include a description of what happens when you deactivate your account, then one would have to check a "I wish to deactivate my account" checkbox, select a "proceed" button, which would then pop up a secondary confirmation overlay with a "confirm" or "cancel" button.

3) Deactivation would perform the following functions

3.a) The following changes would be made:
- 3.a.1) User title would change to "Inactive User" (ACP configurable, or by phrase)
- 3.a.2) User Signature would be either removed or changed to a custom signature (ACP configurable)
- 3.a.3) About me cleared
- 3.a.4) Custom Fields Cleared
- 3.a.5) Occupation, Website, Location, etc cleared (perhaps ACP checklist for what gets cleared)

3.b) The following would remain in tact:
- 3.b.1) Username
- 3.b.2) Profile page posts (all)
- 3.b.3) Forum content (all)
- 3.b.4) Media, Resources, etc
- 3.b.5) Ability to log into account

3.c) User Avatar change would be selectable via ACP:
- 3.c.1) No change (leave avatar as-is)
- 3.c.2) Delete/reset (revert to default)
- 3.c.3) Change to custom avatar


3.d) User would be removed from all secondary usergroups
- 3.d.1) configurable via ACP: there might be a reason to not remove someone from a particular secondary group; for instance, a paid upgrade group - if they are just throwing a hissy, and a month later they re-activate, their paid subscription might still be active.

3.e) After 3.d, user would:
- 3.e.1) optionally be added to a specified secondary user group or groups (selected by admin, likely "Inactive") where special permissions could be configured for inactive users, and
- 3.e.2) optionally have their primary user group changed to a specified group (selected by admin, likely "Inactive"). Note: this is actually my preference, as it makes it easy to weed out inactive users from mailing lists, etc...I don't have to select "not part of Inactive users" anymore. They're just in a different "class".

3.f) Inhibit the ability for:
- 3.f.1) anyone to start a conversation with inactive user
- 3.f.2) anyone to send a conv message in an existing conversation to an inactive user
- 3.f.3) deactivated user to start a conversation or send a message
- 3.f.4) some of these might need to be done via permissions; the idea is to prevent conversation messages, but not to permanently remove the user from all conversations (which is not necessarily restorable). Not 100% sure how to handle this one, might just have to remove from all convos.


3.g) Disable email completely. This could probably be done more than one way; currently what I have done is change their User State to "Email invalid (bounced)" which inhibits everything no matter what they have set. Ideally, this addon would add another user state, however I could see this being problematic when the addon gets disabled or removed, as messing with User States might become an issue. I would be OK with changing the User State to the built-in "Email invalid (bounced)". Reactivation takes care of this, more on that later

3.h) Provide admin ability (via ACP) to de-activate user account via one-click button with overlay confirmation.

4) Reactivation

4.a) User may re-activate account by logging into account and clicking "re-activate" button.
- 4.a.1) this may be similar in nature to what is seen when their email bounces; a system notification. However, it should be more in-your-face.
- 4.a.2) here is where the conundrum lies related to disabling email. If the addon causes email to become totally disabled, and the user forgets their password and they need to reset it, how do they get the email? Oh, the vicous circle of life's Catch-22's. Unless the built-in "send confirmation email" is allowed when the user state is "email invalid (bounced)"...which I believe, it does.
- 4.a.3) optionally, admin/mod interaction to re-activate account my be required.
- 4.a.4) intention to reactivate account may instead be more appropriately performed by an Admin; the problem of the vicious circle is solved by forcing someone (regardless of whether or not they remember their username, email, or password) to fill out a form where they provide their current email address, as well as what they think their username and/or email was, and their request for re-activation. This actually would solve an issue we have, which is post-conversion password wiped (due to custom conversion), so now when someone needs to re-activate an account with an invalid (old) email, they can't get their confirmation email to change their password...

4.b) Restore usergroup states to what they would be had they just registered
- 4.b.1) This would mean removing them from any "inactive" user group they were added to, and changing the primary group if that was done, but not affecting the excluded groups.

5) Possible gotchas
5.a) I can forsee a potential bug where users were placed into a certain secondary group at first, and then somewhere along the line they were placed into 2 groups or maybe a different group. When they go to get "reset" this might throw an error. Changing the ACP settings for which groups one is added to or removed from should be applied to all pertinent users once a change is made, such that all users who are deemed "inactive" are always kept in the same subset of user groups at all time.

That's what I've got so far. Any additions, opinions, etc? Toss 'em out there!
 

Robust

Well-known member
#8
Worth noting that you still need to comply with data protection laws. If any information you hold on a user identifies an account or any data to an individual, email is probably close enough to identify that to a living individual (IANAL), so you should probably be registering as a data controller. If email is enough to identify data you have stored to a living person, then you're also required to remove their user data on request. Their content maybe not, but their personal details for sure.
 

Floyd R Turbo

Well-known member
#9
so you should probably be registering as a data controller.
Not sure what this means? Is this an EU thing? Wouldn't you have to do this just by operating a forum, if this is applicable?

If email is enough to identify data you have stored to a living person, then you're also required to remove their user data on request. Their content maybe not, but their personal details for sure.
This is a good point; things to be added under 3.a. This could impact Username and Email address.

For Username, if they used their real name, this gets tricky. This might require the user to check a box stating this is personally identifiable and then enter in a replacement username to take place of their current one. This would also have to bypass "formerly Dave Smith" functionality of username changes.

If it's on the forum owner to ensure identifiable info is removed, this might require manual intervention on every deactivation. If email qualifies, this is simple - specify a default dummy email "inactive1234@myforum.com" where 1234 is the user ID.

The user would be emailed this information one time so they could use the username and their current password to re-activate in the future. Then it's on them.
 

sheel

Active member
#10
Not sure what this means? Is this an EU thing?
Yes. It's a term in the new "General Data Protection Regulation" which gets into force at some point in 2018.

https://en.wikipedia.org/wiki/General_Data_Protection_Regulation
http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679

But, I can't remember every single clause, but I'm pretty sure the universal registration requirement was dropped in 2015 (thankfully some people still have common sense)

(Compared with the stuff the usual incompetent+corrupt people produce, that law is actually somewhat sane.)
 
Last edited:

Floyd R Turbo

Well-known member
#12
Some of those features might interfere with other addons with similar features. For instance, user essentials. I was really wanting a stand-alone addon (single purpose)

But for arguments sake, can you elaborate on which of my posted features your addon covers and which it does not?
 

katsulynx

Well-known member
#13
Some of those features might interfere with other addons with similar features. For instance, user essentials.
There shouldn't be any clashes. Everything can be turned on/off to your liking, so you won't have to worry about anything being available twice. It also might be worth noting that the add-on is for XF2, so at least as of now, there won't be too much surface for such clashes anyway.

But for arguments sake, can you elaborate on which of my posted features your addon covers and which it does not?
Sure.

1) On user's Account Details page, add a section under Settings: Deactivate Account
Implemented.

2) The Deactivate Account page would include a description of what happens when you deactivate your account, then one would have to check a "I wish to deactivate my account" checkbox, select a "proceed" button, which would then pop up a secondary confirmation overlay with a "confirm" or "cancel" button.
The description is there, but no 'cancel' button. I decided it would be additional bloat, as you can simply leave the site if you have changed your mind.

3.a) The following changes would be made:
- 3.a.1) User title would change to "Inactive User" (ACP configurable, or by phrase)
- 3.a.2) User Signature would be either removed or changed to a custom signature (ACP configurable)
- 3.a.3) About me cleared
- 3.a.4) Custom Fields Cleared
- 3.a.5) Occupation, Website, Location, etc cleared (perhaps ACP checklist for what gets cleared)
None of these, but if the demand exists, I can build that in for sure.

3.b) The following would remain in tact:
- 3.b.1) Username
- 3.b.2) Profile page posts (all)
- 3.b.3) Forum content (all)
- 3.b.4) Media, Resources, etc
- 3.b.5) Ability to log into account
I'm currently utilizing XenForos 'disabled' state for user accounts, so all ob these are as required.

3.c) User Avatar change would be selectable via ACP:
- 3.c.1) No change (leave avatar as-is)
- 3.c.2) Delete/reset (revert to default)
- 3.c.3) Change to custom avatar

3.d) User would be removed from all secondary usergroups
- 3.d.1) configurable via ACP: there might be a reason to not remove someone from a particular secondary group; for instance, a paid upgrade group - if they are just throwing a hissy, and a month later they re-activate, their paid subscription might still be active.
They're not removed from any user groups at the moment, but that could be implemented.

3.e) After 3.d, user would:
- 3.e.1) optionally be added to a specified secondary user group or groups (selected by admin, likely "Inactive") where special permissions could be configured for inactive users, and
- 3.e.2) optionally have their primary user group changed to a specified group (selected by admin, likely "Inactive"). Note: this is actually my preference, as it makes it easy to weed out inactive users from mailing lists, etc...I don't have to select "not part of Inactive users" anymore. They're just in a different "class".
The disabled state blocks users from viewing any page other than the reactivation page, so setting up special permissions is likely unneeded. For e-mail filtering, you can go by the user state (as you likely would only send mails to active users anyway, that should pose a sufficient way to distinguish them).

3.f) Inhibit the ability for:
- 3.f.1) anyone to start a conversation with inactive user
- 3.f.2) anyone to send a conv message in an existing conversation to an inactive user
- 3.f.3) deactivated user to start a conversation or send a message
- 3.f.4) some of these might need to be done via permissions; the idea is to prevent conversation messages, but not to permanently remove the user from all conversations (which is not necessarily restorable). Not 100% sure how to handle this one, might just have to remove from all convos.
As above, they're blocked from each and any action, just as the XenForo default disabled state.

3.g) Disable email completely. This could probably be done more than one way; currently what I have done is change their User State to "Email invalid (bounced)" which inhibits everything no matter what they have set. Ideally, this addon would add another user state, however I could see this being problematic when the addon gets disabled or removed, as messing with User States might become an issue. I would be OK with changing the User State to the built-in "Email invalid (bounced)". Reactivation takes care of this, more on that later
I'm actually not sure, but I believe they shouldn't receive any more e-mails for the duration of their inactivity.

3.h) Provide admin ability (via ACP) to de-activate user account via one-click button with overlay confirmation.
That's alread built into XenForo. Not 'one-click', but you can change it where you edit all other XenForo user information. I've extended my deactivation log, so it would be easy to extend any above functionality as well without much cost.

4) Reactivation

4.a) User may re-activate account by logging into account and clicking "re-activate" button.
- 4.a.1) this may be similar in nature to what is seen when their email bounces; a system notification. However, it should be more in-your-face.
- 4.a.2) here is where the conundrum lies related to disabling email. If the addon causes email to become totally disabled, and the user forgets their password and they need to reset it, how do they get the email? Oh, the vicous circle of life's Catch-22's. Unless the built-in "send confirmation email" is allowed when the user state is "email invalid (bounced)"...which I believe, it does.
- 4.a.3) optionally, admin/mod interaction to re-activate account my be required.
- 4.a.4) intention to reactivate account may instead be more appropriately performed by an Admin; the problem of the vicious circle is solved by forcing someone (regardless of whether or not they remember their username, email, or password) to fill out a form where they provide their current email address, as well as what they think their username and/or email was, and their request for re-activation. This actually would solve an issue we have, which is post-conversion password wiped (due to custom conversion), so now when someone needs to re-activate an account with an invalid (old) email, they can't get their confirmation email to change their password...
You're able to set up for how long users are able to reactivate their account per user group (permission). You can either set it so they can never reactivate their account, reactivate it within the next X days or do so whenever they like in the future. The selected date is saved, so even if you change the permission or the groups of the user later, it will remain intact and they get exactly the date you promised them upon deactivation.

The XenForo-Login system stays intact, so they still receive their password e-mails and the like. They also have access to the 'Contact Us'-form in case they need help.

4.b) Restore usergroup states to what they would be had they just registered
- 4.b.1) This would mean removing them from any "inactive" user group they were added to, and changing the primary group if that was done, but not affecting the excluded groups.
I could save a snapshot of all usergroups upon deactivation and restore it upon reactivation, but I can't really see the use this would have in the current state, as there is not really a point in removing them in the first place.