The component that is being emailed isn’t being sent as the result of a user action. It is being sent as part of a quartz job. For a bunch of fetched EO’s, their global ID’s are passed to a method that uses ERMailUtils.instantiatePage to create an instance
of the component for each EO. This all happens outside of userland.
is called. Not sure if that is necessary.
On Apr 23, 2015, at 3:07 PM, Chuck Hill <
email@hidden> wrote:
Hi Tim,
It is probably because your email is using component actions instead of direct actions. Component actions require a session and are definitely not what you want in an email. For WOHyperlink, as an example, you need to bind directActionName instead of
action.
Chuck
On 2015-04-23, 12:25 PM, "Timothy Worman" wrote:
In my app I am tracking session creation - as a way to sniff out some issues I’ve had with some going stray. Anyhow, I am sending NSArray<EOGlobalID> to a background task that sends emails using ERMailDeliveryHTML. These are component based emails.
Low and behold, each and every one creates a new session. Certainly I understand why this could/would happen depending on the contents of the component/page.
I am most curiouser about what approaches decent WO folk might use to avoid this. This is how I’m abusing things:
for(Object aPersonGlobalIdObject : approverIds.toArray()) {
EOGlobalID aGlobalID = (EOGlobalID)aPersonGlobalIdObject;
MyComponent _component = (MyComponent) ERMailUtils.instantiatePage("MyComponent", null);
_component.setGlobalId(aGlobalID);
try {
_component.sendThisComponentToPerson();
}
other stuff….
}
I had thought ERMailUtils.instantiatePage was made for doing this without creating a session? But I must have fooled myself.
Tim Worman
UCLA GSE&IS