Its great that we are able to impersonate users, which is good for support and keeping track of businesses, however, for security and privacy, i think this feature should have more controls.
Eg, impersonate should allow timestamps as well, as per the administrator’s settings. So maybe impersonate with timestamp or without. To leave trace, incase someone is entering to work on something other users should know what changes he made.
Will avoid administrators misusing that impersonate power.
I agree,
But I think impersonate should be even more limited than what you suggest.
I would argue that it should be implemented only on a surface level, meaning:
This way any action by the impersonator will have the administrator as the actor and not the impersonated user.
I will add this to ideas
But as a disclaimer, that doesn’t place this in for immediate implementation; the developer first has to decide whether this is worth implementing and then it will compete with other ideas for priority.
So @mraniweneonline you may have to live with current implementation for a while.
Yes sure,
I have thought of a slight addition there.
Because the only reason for impersonation is actually to provide support, you are trying to replicate the exact environment as the user you are impersonating so you can replicate the issue they are facing and help them out. Otherwise you can just go in as the administrator since you have access.
In this case, impersonation should work exactly as it is, however, the user being impersonated should give permission, so the administrator will request impersonation, (the user will accept the request) - and then as you have shared, both accounts will be shown as making changes in the history (impersonated user and administrator) and when admin is done, then he can exit, and the session is closed. Meaning next time they have to request again.
If its just an admin wanting to go in, they can just use administrator account in the history it will be shown that they went in and did changes. which is also okay.