Hello ! I am back and glad to have so many feedback :)
Since Nicolas already answered, i'll add some precisions and opinions inline. Le mardi 14 août 2018 à 18:17:14 (+0200), Nicolas Malin a écrit : > Hello, > On 13/08/2018 10:09, Pierre Smits wrote: > > Impressive... > > [...] > The feature haven't the same goal than an OS take-over tool, but just on the > same aspect you can escape problematic like system incompatibility and time > zone. > All is embedded in OFBiz with tracking. And in other time, like an OS > take-over tool you can't use it to trainyour end user. For this part it's > better to use a WebRTC client. +1 it's not a feature to have access to the client computer. It is a feature that OFBiz could offer to impersonate and see through the eyes of another userLogin. I did not recover the previous thread, but I remember that was a basic proposal before the implementation. Nicolas answer did offer you use cases, i hope that will be enough for you to understand the need of such a feature :). [...] > IMPERSONATE_ADMIN is a permission so only OFBiz administrator can assign it > to an user (by the permission SECURITY). +1 : that's a high level permission, so to grant it to a user you need to a trusted admin :), and should be granted to trusted users ! Keep in mind that is an administration tool, and should be used in such aspect. Giving control to all user to the configuration of the possible impersonation of their login is quite strange to me, i do not grasp this need, could you elaborate ? > > I understand your fear to have a high level user that surpass their rights > and use it to damagesome process. We startedwith the idea that all high > level user and OFBiz administrator are trusted peoples, and if not,maybe we > need to track all actions in webtools because currently with permission > ENTITY_MAINT this feature isn't needed. > Most seriously, I see interesting improvement in your remarks that we > shouldnever had two actives sessions on impersonate user. Like this when a > user impersonate an other he will be logged out with an error "You are > currently impersonated by XXX" and he can't login during the impersonation > time. All operations realized during this time can be associate to the > impersonation. This idea is interesting in production environement to ensure that all action made during a time frame is done by the user impersonating. But this should be desactivable for non-production environment. > > What I furthermore feel lacking or underdeveloped is the audit and logging > > trail regarding this feature. Nowhere can be seen what actions (for the > > authentic ID) have been undertaken by the impersonator while the > > impersonation was in progress. Neither in logfiles, nor in screens in the > > Partymgr component (e.g. for the user to see). The above proposal should help the audit of impersonated user in production environment. Since impersonation period is stored, and login desactivated during this period, everything done during it belong to the impersonator ! > > > > I advise the community to be very careful to commit this, without > > consideration of the above, into the repo. Thanks for your feedback, consideration is here :), let's build a good secured feature as a community ! I hope you find this feature interesting ? Reading you, i find out that no documentation is provided yet with this feature, we need to elaborate one, that will help up introducing it to business adopter and ‘boost their confidence’ ! Regards, Gil
