Delete users that were accidentally not deleted

Resolving issue as task itself is done. Some additional work has been identified and put into DBOINCP-452

That means, if we replicate features in Drupal (and inccrease redundancy that way) we need to do it fully, so we'd need to add the manual delete user (by BOINC ID) as well

FWIW, I actually programmed a way to manually delete a user using the Drupal admin interface. It's a undocumented feature. You have to navigate to it manually by knowing the URL and enter the Drupal ID (not BOINC ID) of the user. It will then ask for your (the admin's) password and then delete both the drupal and BOINC users from their respective database tables.

I wrote this with the intention of being able to delete the users that you have already deleted manually, but realized afterwards these users were a special case: they have their Drupal accounts deleted but not their BOINC accounts. Therefore we could not use this feature to delete them. However, I left the code in place because it seemed useful.

DELETE DELAY

Nice catch! I set it to 10s for both project. Now I'm wondering if we should add a spinner (or similar) somewhere to indicate the delete process is indeed running in the background as to not confuse the user and/or cause repeated clicking...?

I would prefer that the delete user functionality be controlled using Drupal and its admin interface, otherwise we will have too many near-duplicated config settings that will be confusing

Hm, yeah, I'm still undecided. OTOH, I definitely share your concern and agree with you. OTOH, there are still other BOINC tools like html/ops/delete_user.php which require the config.xml setting to be configured. That means, if we replicate features in Drupal (and inccrease redundancy that way) we need to do it fully, so we'd need to add the manual delete user (by BOINC ID) as well. Is all that redundancy really better than user calling BOINC's delete_account() and thus make use of what already there and maintained?

Another sub-task for Oliver Behnke:

You may need to add this following define to albert and einstein project.inc in html/project/project.inc

DELETE DELAY from upstream project.inc

We can certainly improve the Drupal front-end code to have similar functionality as the BOINC web code: Have the admin chose what kind of deletion to use: A or B. And even let the user chose between the two options: C = let user choose A or B. Option D could be 'no deletion'. Likewise admins may disable the boincuser_delete module.

I would prefer that the delete user functionality be controlled using Drupal and its admin interface, otherwise we will have too many near-duplicated config settings that will be confusing, even for ourselves in the future. Thus the Drupal module can be enabled/disabled, the admin may choose what type of deletion to run (or let the user decide), etc.

This can all be introduced in another JIRA ticket.

Well, enable_delete_account serves two purposes: a) its a security feature to prevent unintentional account deletions and b) it controls what account deletion actually means. If you're not depending on enable_delete_account then projects don't have a choice, right? Deletion always means "wipe". Since we make use of an original BOINC feature, shouldn't we then support it in a similar way? That is, rather call delete_account() instead such that projects can choose what happens on the BOINC side of things? Right now we're needlessly giving away useful flexibility, I think.