Hello,
On 13/08/2018 10:09, Pierre Smits wrote:
Impressive...
This seems to be an in-OFBiz equivalent of an OS take-over tool like
Microsoft's Remote Desktop. The business case (and use cases) are explained
insufficiently in this thread or in the ticket ([1]) why incorporating this
in the repo should be favourable over having the adopting business
implement implement the OS take-over tool. What I feel missing here (and in
the ticket) is the reference to the previous thread, which might explain
the business case. I suggest to have a link to this thread also in the
ticket
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.
I can give you the business case from our own feedback on a B2B
ecommerce platform context:
* On technical aspect
** Give the opportunity for technical administrator to take the lead
on user account toreproduce front side error. This help to spot quickly
the problem and save precious time for the resolution.
* On functional aspect :
** Help the account validation after is creation. A front side admin
can simulate an account just created to ensure that all configuration
are done before activation
** During big order, if a functional problem raise, a front side admin
can reload the saved cart to finalize it
** To avoid reveiving login information (including password) from the
final user in a non encrypted email (It's not a joke :/ )
* On QA aspect :
** on QA platform, the QA team can use real account to realize their
controls without pass by a password reinitialisation on each need
account at each QA database updated by production database.
Based on a cursory review of the patch, it is lacking serious aspects that
will boost the confidence of any business adopter that this feature will
not jeopardise their business operations. As it is now, I find the patch to
basic to be committed to the repo and be included in any new release.
As I see it it allows anybody with the IMPERSONATE_ADMIN permission take
over any other ID and perform actions under that ID at anytime. I did not
see any functionality (I am spitballing here) that:
1. would exclude any particular ID from being taken over (as a default
configuration)
2. would allow a user to disable the feature for their own account
(overriding the default permission of impersonation)
3. would allow a user to explicitly allow its ID to be taken over by
someone else, AND limit it for a specific amount of time (overriding aspect
#2 above).
4. would prohibit the impersonator to take over an ID when the user of
the ID is NOT logged in (which should be an additional default aspect).
This feature seems 'impersonator' driven as the permission would not be on
a case-by-case scenario, but rather on a semi-permanent permission
assignment and by a user who has the - technical - permission to set such
a permission.
We keptin mind that IMPERSONATE_ADMIN is a high level permission, given
to high level user on the platform or business process.
A user with this permission can't impersonate an other user with more
permissions than him. This is missing on the latest patch and need to be
updated.
IMPERSONATE_ADMIN is a permission so only OFBiz administrator can assign
it to an user (by the permission SECURITY).
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.
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).
I advise the community to be very careful to commit this, without
consideration of the above, into the repo.
With the idea to enable/disable impersonate, we can just manage it with
the permission. If we want, we can load ittoFULLADMIN/SUPER permission
groupotherwise remove this permission. So simple issue would be to
include this permission only on demo data and not seed data.
Cheers,
Nicolas
[1] https://issues.apache.org/jira/browse/OFBIZ-10515
Best regards,
Pierre Smits
Apache Trafodion <https://trafodion.apache.org>, Vice President
Apache Directory <https://directory.apache.org>, PMC Member
Apache Incubator <https://incubator.apache.org>, committer
Apache OFBiz <https://ofbiz.apache.org>, contributor since 2008
Apache Steve <https://steve.apache.org>, committer
On Mon, Aug 13, 2018 at 6:19 AM, Zhang Wei <tzn...@msn.com> wrote:
+1
________________________________
发件人: Rajesh Mallah <mallah.raj...@gmail.com>
发送时间: 2018年8月11日 11:10
收件人: dev@ofbiz.apache.org
主题: Re: New Impersonate Feature : OFBIZ-10515
This feature has valid use cases.
+1
On Sat, Aug 11, 2018 at 1:30 AM, Gil Portenseigne <
gil.portensei...@nereide.fr> wrote:
Hello !
I would like to introduce to you a new feature, i already talked about
some
time ago (last year?). We needed it for one of our customer, that is
using it for some time and is very happy with it (like we are).
Indeed this impersonation feature comes to be very useful when we need
to validate some behaviour or to assist a user in production without
asking for its credential. It's became so easy to use that even in
preproduction/integration environment we use it daily to impersonate
specific configured userlogin without trying to remember the password...
It's kinda basic, a new permission is created and can be granted to an
authorized user, that will be offered a way to select a userlogin to
impersonate.
It's a common feature that can be found for example in Gitlab.
If you wanna try it out it's available here :
https://issues.apache.org/jira/browse/OFBIZ-10515
Feedback are welcomed :), although i'll be partly offline next week.
Looking forward reading you !
Gil
