locked
Get UserId from IOrganizationService? RRS feed

  • Question

  • Given the IOrganizationService "service" created in a workflow as shown below, is there a way to get back the context.UserId?  A WhoAmIRequest returns SYSTEM.  The workflow is an organization scope workflow.

    Thanks.

     

                    IWorkflowContext context = executionContext.GetExtension<IWorkflowContext>();
                    IOrganizationServiceFactory serviceFactory = executionContext.GetExtension<IOrganizationServiceFactory>();
                    IOrganizationService service = serviceFactory.CreateOrganizationService(context.UserId);
    

     


    • Edited by simdoc Thursday, January 26, 2012 11:29 PM
    Monday, January 23, 2012 11:19 PM

Answers

  • If you don't have access to the IWorkflowContext and you don't want to change the signatures, there are two things that you can do, neither of which are very good:

    • Create a temporary entity and retrieve it, which will give you the current user (since the ownerid is automatically populated).
    • Create another plug-in or Workflow that triggers on some operation. You can call that operation from your Workflow activity, which can provide you with the user id.

    My recommendation would be to update your code.

    Michael

    Thursday, January 26, 2012 11:37 PM

All replies

  • The WhoAmIRequest will always return "SYSTEM" from a plug-in or Workflow, because third party code running on the server is running in the context of SYSTEM. When you specify a different user to the IOrganizationServiceFactory, the SYSTEM user is doing something on behalf of the new user (context.UserId in your code). When code calls in from the client, the code executes in the context of the calling user (instead of SYSTEM), which is why WhoAmIRequest will return the correct user in this scenario.

    If you are looking for the user id, simply use the value in context.UserId. If you are looking for the SystemUser record, call service.Retrieve("systemuser", context.UserId, new ColumnSet());. If you use the "service" object from above, the service will behave as if you are running in the context of the "context.UserId" user (except in the case of WhoAmIRequest).

    Michael

    Thursday, January 26, 2012 11:22 PM
  • "context.UserId" is not available at the point where I'm at.  I'm extending a class method that has already had its argument list set and it doesn't include the context.UserId.  I only have the IOrganizationService.  Since this method is used by several different users besides me and other contractors, I would have to get all of the individuals involved to make the change.  Obviously, this can be done, but I thought there would be a simple way to obtain this information from the IOrganizationService.
    Thursday, January 26, 2012 11:29 PM
  • If you don't have access to the IWorkflowContext and you don't want to change the signatures, there are two things that you can do, neither of which are very good:

    • Create a temporary entity and retrieve it, which will give you the current user (since the ownerid is automatically populated).
    • Create another plug-in or Workflow that triggers on some operation. You can call that operation from your Workflow activity, which can provide you with the user id.

    My recommendation would be to update your code.

    Michael

    Thursday, January 26, 2012 11:37 PM
  • If that's all that can be done, we'll do it.  I just wanted to make sure something easier wasn't available.--Thanks.
    • Edited by simdoc Friday, January 27, 2012 1:17 AM
    Friday, January 27, 2012 1:17 AM
  •   CallingUserId = ((WhoAmIResponse)_service.Execute(new WhoAmIRequest())).UserId;
    
    Monday, October 21, 2013 12:00 PM
  • Max this returns SYSTEM when exeucted on IOrganizationService from plugincontext, as Michael mentioned above. I am facing exact same situation as Simdoc. Though i have the choice of changing code, however i wish i did not need to. As a principle i always question myself before making signatures changes in public methods. Based on the name WhoAmIRequest and while plugin step is registered to run in calling user's context, one naturally assumes that WhoAmIResponse UserId would be same as what is PluginContext UsedId, but unfortunately not. I understand that System user does things on behalf of calling user, but those are implementation level details, which do not need to be exposed. The API should behave same whether used from authenticated proxy or from plugin or workflow context
    Monday, October 28, 2013 11:54 PM
  • An observation though, in synchronous pipeline, both in pre & post stage of delete entity (whether organization or user owned) the UserId in PluginContext is SYSTEM user. This is not the case of create & update messages. Could there be more surprises for other messages ?
    Friday, November 1, 2013 1:16 PM