Disable users and spaces in a way that doesn't conflict with new users/spaces

[mconf-daileon]

---

Author Name: Leonardo Daronco (Leonardo Daronco) Original Redmine Issue: 1883, http://dev.mconf.org/redmine/issues/1883

---

When disabling a user, for example, the User instance will still be kept in the database with all the same attributes the user had before being disabled. So, if a person disables his/her account and tries to create it again, it will fail because there's already an account with the same email.

Disabled resources should not conflict with new resources created, especially because the users actually think the resource is being removed but it's actually being disabled.

[mconf-daileon]

---

Original Redmine Comment Author Name: Lucas Zawacki (Lucas Zawacki) Original Date: 2016-04-05T20:51:29Z

---

In case of a user returning to a disabled account, should we ask for a password and allow the user to re-enable the account?

[daronco]

After 0391082bc8aca1387ebc92a7a2559e2713fb8f2b (and related commits), now the unique attributes of a user (e.g. email, username, room name) are renamed when the user is disabled. When the user is enabled again, the attributes are renamed back to their original values. While the user is disabled, it can register again using the same email and username. If an admin then tries to enable the user previously disabled, it will not work because there is already a new user with the unique attributes of the disabled user.

This is a solution for users only, but could be done for all types of resources. It should be done in the "disable modules" (lib/mconf/disable_module and lib/mconf/disable_controller_module) in a generic way that works for all resources. Also, it could store a hash with the original values of the attributes that changed instead of relying in string substitutions, so that when the resource is enabled it will always revert the attributes back to the correct original values.