You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It happens more than one would hope that admins erroneously delete users. This is an irreversible process (you then have to restore a database backup of previous days, deleting all that happened on the portal since then). A better way to reduce this kind of issues would be to have a buffer, a "trash can" where users can still be recovered for a while.
This, however, means that we need a status for a "deleted" user. Currently, we use the user.active field to determine whether a user is active or not. This field is defined in the Entity as Boolean, which will have to be changed to int so we can use "-2" as a value for "deleted". The User::isActive() method will return an int (-2 for deleted, -1 for expired, 0 for inactive and 1 for active).
This action is applied across multi URLs. If the user is "deleted" from the system (which normally is not an action taken at the URL level unless the user was created there), the user.active field is set to -1 and disappears from all lists (except the "trashcan" page users list), so no change is needed at the resource_link level.
To do:
update entity and migration to set "active" as int instead of bool
update entity so isActive() returns true on value 1, and false otherwise
update entity setActive() and getActive() to support int param/return value instead of bool
update all code correspondingly (make sure we use isActive() instead of getActive())
in UserRepository, update deleteUser() to take a second parameter bool $destroy = false that only really deletes the user when the param is true, otherwise it just does $user->setActive(-2);
in all users lists, make sure the user does not appear if he's been deleted (where active != -2)
create a new tab in admin users list to see the deleted users (only select those users where active = -2), where there are only 3 options: edit, restore and delete (which really deletes the user then, calling $userRepository->deleteUser($user, true)).
It happens more than one would hope that admins erroneously delete users. This is an irreversible process (you then have to restore a database backup of previous days, deleting all that happened on the portal since then). A better way to reduce this kind of issues would be to have a buffer, a "trash can" where users can still be recovered for a while.
This, however, means that we need a status for a "deleted" user. Currently, we use the user.active field to determine whether a user is active or not. This field is defined in the Entity as Boolean, which will have to be changed to int so we can use "-2" as a value for "deleted". The User::isActive() method will return an int (-2 for deleted, -1 for expired, 0 for inactive and 1 for active).
This action is applied across multi URLs. If the user is "deleted" from the system (which normally is not an action taken at the URL level unless the user was created there), the user.active field is set to -1 and disappears from all lists (except the "trashcan" page users list), so no change is needed at the resource_link level.
To do:
isActive()
instead ofgetActive()
)deleteUser()
to take a second parameterbool $destroy = false
that only really deletes the user when the param is true, otherwise it just does$user->setActive(-2);
where active != -2
)where active = -2
), where there are only 3 options: edit, restore and delete (which really deletes the user then, calling$userRepository->deleteUser($user, true)
).This issue is related to #5212.
The text was updated successfully, but these errors were encountered: