End-User Options - Self Delete: Allow users to self-delete their account

Self Delete: Allow users to self-delete their account

What is it? This modification allows users to self-delete their account if they have permission. This modification is a port to vB 3.6.8 from a port to vB 3.5.3 of AlphaWolf's 'Self Delete' modification for vB 3.0.3.

New Features: This latest port comes with the following new features:

• Can permit or deny self deletion usage by usergroup
• Can force cool off time period before deletion occurs
• Can send confirmation code to user via PM and/or email
• Can receive reason for deletion via email if provided
• Can send email to user confirming deletion by usergroup
• User can stop deletion if user is in cool off time period

Requirements: vB 3.6.6+ as template hooks are used (only tested on vB 3.6.8)

Does it work on vB 3.5 and vB 3.6? See the requirements.

AngelBlue adds an option: If you wish to place members into a special usergroup instead of removing them, see this post.

Port Information: Ported to vB 3.6.8 with permission via AlphaWolf's post:

https://vborg.vbsupport.ru/showpost....9&postcount=32

Originally Posted by AlphaWolf

I do not have the new 3.5 Version:disappointed:

Maybe someone other is able to port it to the new version. Here is the permission for everyone. Just gimme credit

/**
* Original Self Delete Hack
* https://vborg.vbsupport.ru/showthread.php?t=72932
* @copyright 2004 by AlphaWolf ( http://www.celebdb.de )
**/

[Videx]

AngelBlue, you're most of the way to a whole separate mod "Virtual Delete a user". This is an often requested feature. Why don't you take it all the way?

[Soonerdude]

AngelBlue, if the virtually deleted member decided to return later, can they just be moved back to their original usergroup and be just like they were before?

[velias]

Originally Posted by Mike-D

When your Link inside the UserCP isn't showing up, your Template isn't corrected edited. Here's the way...

Template USERCP_SHELL => Search / Insert

<tr>
  <td class="$navclass[attachments]" nowrap="nowrap"><a class="smallfont" href="profile.php?$session[sessionurl]do=editattachments">$vbphrase[attachments]</a></td>
</tr>

<!-- Self Delete Account -->
<tr>
  <td class="$navclass[sd_kill]" nowrap="nowrap"><a class="smallfont" href="profile.php?$session[sessionurl]do=delacc">$vbphrase[sd_delacc]</a></td>
</tr>
<!-- / Self Delete Account -->

In case of using TMS...

<templateedits> <!-- TMS Replacements --> 	
  <templateedit template="USERCP_SHELL" varname="sd_link_usercp" username="MikeD" version="3.6.8" searchorder="5">
  <title>UserCP Link Einf?gen</title>
  <searchstr><![CDATA[<tr>
  <td class="$navclass[attachments]" nowrap="nowrap"><a class="smallfont" href="profile.php?$session[sessionurl]do=editattachments">$vbphrase[attachments]</a></td>
</tr>]]></searchstr>
	
  <replacestr><![CDATA[<tr>
  <td class="$navclass[attachments]" nowrap="nowrap"><a class="smallfont" href="profile.php?$session[sessionurl]do=editattachments">$vbphrase[attachments]</a></td>
  </tr>
<!-- Self Delete Account -->
  <tr>
  <td class="$navclass[sd_kill]" nowrap="nowrap"><a class="smallfont" href="profile.php?$session[sessionurl]do=delacc"><Font Color="Red">$vbphrase[sd_delacc]</Font></a></td>
  </tr>
<!-- / Self Delete Account -->]]></replacestr>
  </templateedit>
</templateedits> <!-- / TMS Replacements -->

YOUR-SITE.com/YOUR-FORUM/profile.php?do=delacc

Don?t work??

[AngelBlue]

Originally Posted by Videx

AngelBlue, you're most of the way to a whole separate mod "Virtual Delete a user". This is an often requested feature. Why don't you take it all the way?

Several reasons.
First is that I would like people to test my modified version of this hack before I release it as my own product. After all, testing is good
Second is that I'd prefer, for simplicity, that the two hacks were merged into one. Why have two very similar hacks? Why not just have one hack with the option to toggle between the two modes of behaviour? My version of calorie's mod includes a setting in vB options that toggles between either using my "disable, but don't delete" method, or using calorie's "really remove them from the database" method. Calorie could include my code in this mod, adding another option to the mod with no effort required on his part.

If he decides that he doesn't want to use my code, I will probably release my own version of the virtual self delete hack, with the ability to do both what calorie's mod can do and also support the virtual or "fake" deletion behaviour. If calorie really doesn't want me using his code in my mod, I could probably strip out his code and create an entirely different fake deletion mod, based on the same principles, but without using this code. I really don't want to do this, however, as I would consider it reinventing the wheel, and hence, a waste of effort. I think it would be much better if calorie included my code in his mod, or at least, replied here saying that it would be OK for me to create a development fork of his mod to explore adding to the virtual/fake deletion code... maybe they could be merged later once the fake deletion part of it has been tested for awhile and I've added a few more things that I think would be nice to add.

Originally Posted by Soonerdude

AngelBlue, if the virtually deleted member decided to return later, can they just be moved back to their original usergroup and be just like they were before?

Yes, simply changing their usergroup back to any other usergroup will completely reverse the effect of the "deletion". However... I advise against doing this, because if you do, then users will quickly figure out that "deleted" accounts *aren't* really deleted.

In future, I plan to have the option to either phrase this as a "delete" mod (useful if you don't re-activate accounts that users want deleted, but you want to keep them on file anyway)... or a disable mod (useful if you don't want to suggest to your users that their accounts are gone forever, or you aren't able to do so because you sometimes reactivate them).

I'd also like to add a "permit self re-enable" option, which, if enabled, causes the account to be un-deleted when the owner logs in and clicks a link. If disabled, behaviour would be as currently, where once deleted, the account cannot be used and admin intervention is required to re-enable it.

It would probably be possible for me to expand this fake deletion system into a system whereby users could choose, from a set drop-down menu, a list of usergroups to move their account to. Deletion would be one of those options... but there might be other options, too... like newbies having a choice of setting their account to the "Men" or "Women" groups, and getting access accordingly (but, that doesn't necessarily mean that the admin would have to allow movement from the Men group to the Women group, or vice versa!).

In effect this system could be expanded to a usergroup movement flowchart, where admins define which usergroups allow their members to move to which other usergroups. Allowing all accounts to set themselves "deleted" (fake deleted, I mean) might be one option there.

[b6gm6n]

3.7 beta (i think here) all works, anyone know about the blank email sent to webmaster account after the 'whatever marked for deletion' email? usually after the cool off period the webmaster then gets a blank

[AngelBlue]

I have split away the code that I was using to provide 'fake deletion' behaviour into a separate fake deletion mod.

Compatibility with this "Self Delete: allow users to self-delete their account" mod by calorie is provided in the form of a very easy integration... simply replace one of the files calorie's mod uses with the one that I provided in this post.

For further discussion of the fake deletion mod, please post in my thread on the subject, as I don't want to create a bunch of off-topic replies in this thread.

[quasan]

needs an update for 3.6.10 security token issue

[MrD]

Here is a xml with SecToken Fix.
Works in 3.6.10 and 3.7.0

[Robru]

Originally Posted by MrD

Here is a xml with SecToken Fix.
Works in 3.6.10 and 3.7.0

Works perfect in vB 3.7.0

[Andy Dean]

Hmmm... seem to have a problem, when the cool off period is set to 0 accounts are deleted straight away, but when i set it to 60, accounts don't delete, even when running the hourly cleanup crons. Everything worked fine before 3.7, can anyone help?