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.