Remember we always must check it's not empty if we want' to rely on it for loading/restoring users.

Ciao

this fix breaks things If you look at the CVS logs, you'll notice we keep playing revert wars on this. I remove the data-munging-on-delete, someone else adds it again :-/

Here is what happens:

• Auth plugins delete users if they see the user disappear from the 'backend'. However, the user may 'revive'/'reappear'. The disappearance may have been temporary (bugs in the backend data export that are fixed, students that take a semester off and return). In those cases we must retain the user identity and revive the user, so their old data is re-associated to the same user.

And for that, we need to retain username and idnumber... and often email.

• The default email self-registration machinery has no "revive user" mechanism, so when I "fix" auth plugins by keeping data intact upon deletion, users complain because they cannot "re-register". The easy fix is to remove the old data (what your patch does).

IMHO, the right thing is:

• keep the original data, don't corrupt it
• add a "your username / email addr is in our DB!, want to reset your password?" workflow that knows how to revive the user acct.

I still think the right way is to preserve the real data, and get the "revive user acct" thing going, probably hooked w the password reset.

it is not possible to cope with cases where users are appearing and disappearing in external systems, instead of deleting those "unreliable" auth plugins should disable the account somehow (I already proposed a new db field for that in 2.0, others did not like it, well I might try to push it through again during the hackfest)

technically Eloy's latest change does not remove more data imho, instead it helps to identify deleted users - I do not see any problem in that

I agree this needs to be addressed properly in 2.0, this is also related to enrolments.

And that md5() will allow others (restore, import users, auth plugins...) to detect better deleted users (by md5(username)). It was simple impossible to do that with confidence before.

About reviving, rekilling, exterminating and friends, I really haven't a clear idea at all (but the basic notion that the record (the id) must survive forever in the DB. Surely, with some clever rework of auth plugins and friends, we'll be able to do those things in an standard way. In fact, having the username hash used for that... anyway that is another story.

So, if changing email DB contents (of deleted users) from empty() to md5(username) doesn't affect anything, I'd keep that way forever/until some better alternative arrive. I'm going to get immediate benefits matching deleted users on restore (avoiding current "revive everybody" wrong approach).

Thanks ML!

Ciao

Ciao