drupal 7 upgrade path

In fact, I would actually recommend to go preparing an upgrade path, because the D6 and D7 versions are quite different in configuration and functionality.

I'm considering making a backport of http://drupal.org/node/224333#user_cancel API in user_cancellation module. If you think this could be also done in user_delete I'd provide patches to make it works as a real backport (probably some features would have to go out).

I agree LPCA, so I requested ownership of the user_cancellation module, and that would do to help in the merging of this two modules.

Instead of start warning users in the frontpage of the module, I'd first make sure we can get the configuration of user_delete 6.x as compatible as possible with D7 settings, to provide a good upgrade path once the site upgrades to D7.

But this might require some string changes as 'Delete user' and 'cancel account' are two different terms and process.

I've reviewing D7 code and current user_delete code, and these are the conclusions:

For a D7 upgrade, the module user_delete requires the following changes:

- Include batch API as a dependence, to perform operations in a batch process.
- Finally have two permissions: 'cancel account' and 'select account cancellation method'
- Have a variable called: 'user_cancel_method' that holds a string containing the default cancel method.
- Include a cancellation link method.
- Include a new email 'cancel_confirm' to confirm the account deletion.
- A default set of methods called:
'user_cancel_block' to Disable the account and keep all content
'user_cancel_block_unpublish' to Disable the account and unpublish all content.
'user_cancel_reassign' to Delete the account and make all content belong to the anonymous user.
'user_cancel_delete' to Delete the account and all content.
- Any other funcionality, like redirecting the user to another location, showing a message or keep content during N weeks should be provided as another contrib module, because once upgraded to D7 all these functionality will get lost. Using another module, the functionality can remain using the D7 version of the same contrib module without requiring user_delete module anymore.

I have coded a user_delete_example module today as a template about how 'keep content for n weeks' can be done #933624: User API example including user cancel.

It is important to finally have the same 'logic' in the module, so upgrading to D7 is just 'disable the module' and keep working as it is now.

Strings in the D7 version are different from this module with core, this are the strings from the D7 version.

Are you sure you want to cancel your account?
Are you sure you want to cancel the account %name?
Select the method to cancel the account above.
Disable the account and keep all content.
Your account will be blocked and you will no longer be able to log in. All of your content will remain attributed to your user name.
Disable the account and unpublish all content.
Your account will be blocked and you will no longer be able to log in. All of your content will be hidden from everyone but administrators.
Delete the account and make all content belong to the %anonymous-name user.
Your account will be removed and all account information deleted. All of your content will be assigned to the %anonymous-name user.
Delete the account and all content.
Your account will be removed and all account information deleted. All of your content will also be deleted.
You have tried to use an account cancellation link that has expired. Please request a new one using the form below.
A confirmation request to cancel your account has been sent to your e-mail address.
Sent account cancellation request to %name %email.
When enabled, the user will receive an e-mail notification after the account has been cancelled.
Notify user when account is canceled.
When enabled, the user must confirm the account cancellation via e-mail.
When cancelling your account
When cancelling the account
Cancel account

To guaranty a safe upgrade path from D6 to D7, current module requires all these changes, but instead of developing several upgrade functions for each change (now that the are no bug issues open) we can create another branch 6--2 or tell current users to NOT update from 6.x-1.3 to -dev or they can lost current configuration during update.

Suggestions? or do I go my own..

Right now I'm backporting D7 user cancel API AS IS. I've completed the basic processing (performed in batch process) with the default D7 settings. Nodes/comments and so on are not being deleted because I've not yet implemented the methods yet, but it is well documented due to the http://api.drupal.org/api/function/hook_user_cancel/7 api in node.module, comment.module, and so on. Once I have user_delete doing the basics, then I'll provide an additional module for the 'features' this version has: keep content N weeks or redirect the user if there is an special interest in it.

The idea in the end is having user_delete doing the same things that D7 does right now, and other modules providing additional functionalities. This way, the D7 upgrade path will be just disable the user_delete module (and upgrade to D7 the modules providing these additional funcionalities: keep content for N weeks, and so on.).

Only one update function will be required, the one that would take current variable names and permissions, and set the permissions the same way D7 (and this version of user_delete) has. The real problem will appear in the translations, but as long as I'm using the same strings as in D7 (copy/paste) I'm pretty sure this should not be a problem later, but would require an additional translation process right now.

Once I do have this version usable, I'll create the branch then.

LPCA, you might be interested in this: #935120: Backport D7 user cancel API to Drupal 6