Removing a user does not remove the session_attributes

[Jason Trahan]

I'm not sure if this was by design or not. If it is can you add an option to remove the session_attributes when a user is removed.

[Catalin BALAN]

Yes, this was by design ... which is bad and 'trashy', but safe. I'll fix this soon.

Thank you for your feedback.

Best regards, Catalin Balan

[Steffen Hoffmann]

Replying to cbalan:

Yes, this was by design ... which is bad and 'trashy', but safe. I'll fix this soon.

Safe. Quite right, indeed. In AccountManagerPlugin there was a bug preventing the db cleanup. Just the user was deleted from the password stores. I fixed it meanwhile, but yesterday I helped someone out on #trac IRC channel, who had to recover from extensive erroneous user account deletion. With his still buggy version his admin had not done much harm. You see?

Anyway, this is code available in AccountManagerPlugin. Let's see how to use it here without re-inventing the wheel.

[Steffen Hoffmann]

Closer investigation inside this plugin's source reveals, that UserManager.delete_user for one relies on AccountManager.delete_user that got fixed to delete all attributes since r10526. So all users with a password store entry (recognized by AccountManager as referred to by the term "AccountManager"-managed users) should be sanely wiped.

The other, plugin-native method is still weak, rather disabling user accounts than deleting them, but better leave it that way, hopefully encouraging adoption of the next-generation of AccountManager with UserManager core functions merged, what is planned for the acct_mgr-0.5 release cycle.

Since Catalin will most probably not stay to the promise anymore, I'd read it like wontfix, but leave it open for visibility to prevent duplicates until there is a better alternative thought new, integrated code.