In order to run a custom object, the Platform needs to know for whom the object is to be rendered, in order to ensure that the object accesses the correct data. This is done by defining the context for the custom object. A context is similar to a user, such that the data and Platform functionality available to the rule is restricted to the context defined by this method.
A custom object needs to call Context.create() to specify the context in which to run the object. The create() method is provided from com.axeda.drm.sdk.groovy.AxedaSDKUtils. If the method is called without an argument, then the method defines a system or administrative context. If the method is called with the username argument, then the method will use the context of the logged in user when accessing and rendering data for this custom object.
If Delegated Administration is enabled, an expression rule defined to run a custom object runs in the context of the Delegated Administrator for the DA Unit in which the rule author is defined. For example, if the rule author is defined as a user in DAUnit_A, all expression rules written by that author run in the context of the Delegated Administrator for DAUnit_A. If the rule author is defined in the ROOT DA Unit, the rule runs in the SystemContext.
//returns the admin context (scoped to the current tenancy)
Context sdkContext = Context.getAdminContext()
//returns the context of the logged in user
Context ctx = Context.getUserContext();
Important: Axeda recommends that you always use the Context.getUserContext()method unless you truly need the script to run with admin access.
Context.getUserContext() will run the object in the scope of the user when the object is run from the following:
when called from ScriptoService Web service
when testing custom objects using the Test button in the "Custom Object Test page" of the Custom Object wizard
when configured for display in an Extended UI Module
Context.getUserContext() may run in the context of an admin. If this is not the desired behavior then you should change your code to call it from via Scripto Web service.
Note that the logged in user may not necessarily be the user who authored the script (and likely won't); keep this in mind when creating the object.